Unresolved symbol problem

Unresolved symbol problem

[Anthony Kent]

I hope someone can shed some light on a problem I am having trying to install some modules into perl 5.10.0 compiled with gcc 3.4.6 on HPUX11.11.

From everything I have read exhaustively, it appears that HPUX has particular problems in this area and I have certainly been experiencing plenty of them. Having finally got gcc installed and using it to compile perl 5.10.0 I have been busy loading dozens of modules. All went well until I came to DBD-SQLite-1.14.

perl Makefile.PL 
<path>hp/gnu/make-3.81/bin/make

Both run without reported errors, but when I go on to run

<path>hp/gnu/make-3.81/bin/make test

I am getting the following issues:

PERL_DL_NONLAZY=1 /opt/product/ticm/build_tools/hp/perl/gcc/5.10.0/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00basic.............../usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code)  from /opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __ashldi3 (code)  from /opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __fixunsdfdi (code)  from /opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __umoddi3 (code)  from /opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __moddi3 (code)  from /opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __ashrdi3 (code)  from /opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl
Can't load '/opt/product/ticm/tonydev/CPAN_libs/DBD-SQLite-1.14/blib/arch/auto/DBD/SQLite/SQLite.sl' for module DBD::SQLite: Unresolved external at /net/hn4k022/opt/product/ticm/build_tools/hp/perl/gcc/5.10.0/lib/5.10.0/PA-RISC2.0/DynaLoader.pm line 203.

 at t/00basic.t line 4
Compilation failed in require at t/00basic.t line 4.
BEGIN failed--compilation aborted at t/00basic.t line 4.
# Failed test 1 in t/00basic.t at line 3
#  t/00basic.t line 3 is: END { ok($loaded) }
t/00basic...............dubious
        Test returned status 215 (wstat 55040, 0xd700)
DIED. FAILED test 1
        Failed 1/1 tests, 0.00% okay

I have ensured that I have compiled gcc myself and used it to compile perl and DBD-SQLite-1.14. I’ve tried manually linking SQLite.sl and libgcc.a, but it makes no difference to the results.

I’m not a developer of any sort, just an admin person, so I have rapidly exhausted my knowledge on the subject of compiling and linking. Can anyone advise me on how to resolve these unresolved symbols?

Tony

-----------------------------------------------------
Le bureau virtuel
http://www.lamessagerie.com

Re: Unresolved symbol problem

[Tom Browder]

On Thu, May 15, 2008 at 4:48 AM, Anthony Kent <tonykent@bigfoot.com> wrote:
> I hope someone can shed some light on a problem I am having trying to install some modules into perl 5.10.0 compiled with gcc 3.4.6 on HPUX11.11.
...
> From everything I have read exhaustively, it appears that HPUX has particular problems in this area and I have certainly been experiencing plenty of them. Having finally got gcc installed and using it to compile perl 5.10.0 I have been busy loading dozens of modules. All went well until I

Tony, have you ever tried using the cpan shell for loading Perl
modules?  Sometimes that can solve weird dependencies that us mere
mortals have trouble dealing with.  And it's much easier than dealing
with one module at a time.

-Tom

Re: Unresolved symbol problem

[Anthony Kent]

I have just tried the CPAN shell and unfortunately got exactly the same failure messages on the make test phase:

t/60metadata............/usr/lib/dld.sl: Unresolved symbol: __udivdi3 (code)  from /home/tsbuild/.cpan/build/DBD-SQLite-1.14-n8KpxE/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __ashldi3 (code)  from /home/tsbuild/.cpan/build/DBD-SQLite-1.14-n8KpxE/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __umoddi3 (code)  from /home/tsbuild/.cpan/build/DBD-SQLite-1.14-n8KpxE/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __moddi3 (code)  from /home/tsbuild/.cpan/build/DBD-SQLite-1.14-n8KpxE/blib/arch/auto/DBD/SQLite/SQLite.sl
/usr/lib/dld.sl: Unresolved symbol: __ashrdi3 (code)  from /home/tsbuild/.cpan/build/DBD-SQLite-1.14-n8KpxE/blib/arch/auto/DBD/SQLite/SQLite.sl
install_driver(SQLite) failed: Can't load '/home/tsbuild/.cpan/build/DBD-SQLite-1.14-n8KpxE/blib/arch/auto/DBD/SQLite/SQLite.sl' for module DBD::SQLite: Unresolved external at /net/hn4k022/opt/product/ti
cm/build_tools/hp/perl/gcc/5.10.0/lib/5.10.0/PA-RISC2.0/DynaLoader.pm line 203.
 at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.
Perhaps a required shared library or dll isn't installed where expected
 at t/60metadata.t line 4

I suspect that the gcc library is not being found/declared properly, but I'm not sure how to prove this.

regards

Tony

> ----------------------------------------
> From: Tom Browder <tom.browder@gmail.com>
> Sent: Thu May 15 12:19:34 CEST 2008
> To: Anthony Kent <tonykent@bigfoot.com>
> Subject: Re: Unresolved symbol problem
> 
> 
> On Thu, May 15, 2008 at 4:48 AM, Anthony Kent <tonykent@bigfoot.com> wrote:
> > I hope someone can shed some light on a problem I am having trying to install some modules into perl 5.10.0 compiled with gcc 3.4.6 on HPUX11.11.
> ...
> > From everything I have read exhaustively, it appears that HPUX has particular problems in this area and I have certainly been experiencing plenty of them. Having finally got gcc installed and using it to compile perl 5.10.0 I have been busy loading dozens of modules. All went well until I
> 
> Tony, have you ever tried using the cpan shell for loading Perl
> modules?  Sometimes that can solve weird dependencies that us mere
> mortals have trouble dealing with.  And it's much easier than dealing
> with one module at a time.
> 
> -Tom

-----------------------------------------------------
Le bureau virtuel
http://www.lamessagerie.com

Re: Unresolved symbol problem

[Tom Browder]

On 5/15/08, Anthony Kent <tonykent@bigfoot.com> wrote:
> I have just tried the CPAN shell and unfortunately got exactly the same failure messages on the make test phase:
...
> I suspect that the gcc library is not being found/declared properly, but I'm not sure how to prove this.

Try setting an environment variable to the desired gcc:

export CC='<path-to-gcc>'

And make sure LD_LIBRARY_PATH has the path to your locally-installed libs.

Then remake the module's Makefile.PL and retry the build.

-Tom

P.S.  Are you locked into that old gcc version?

P.P.S.  As administrator, you sure have some ugly paths on that
host--that may be the source of some of the problems (later if not
now) if there are years of old cruft hangin around--especially the way
some Perl packages are cavalier about where modules are installed and
how Perl's @INC is configured.

Re: Unresolved symbol problem

[Anthony Kent]

Tom,

After 3 days of banging my head against brick walls I have found the solution! I am SO pleased.

The problem was the result of inadvertently trying to mix and match gcc and HP tools. I had read about this being a problem and had ensured that I compiled gcc myself then used that to compile perl, make etc.

What I had not realised - as it had not been a problem with and of the other 100+ perl modules I've loaded - is that the Makefile.PL files were using the following settings:

FULL_AR = /usr/bin/ar
LD = /usr/bin/ld
LDDLFLAGS = -b

These are the HP tools obviously. Whilst they appear to work happily in most instances, certain perl modules won't compile/link with HP tools when using gcc-compiled perl etc.

I changed the Makefile.PL of DBD-SQLite-1.14 and Crypt-SSLeay-0.57 (the 2 difficult ones so far) to point to the gcc-compiled tools:

FULL_AR = /opt/product/ticm/build_tools/hp/binutil/binutil-2.18/bin/ar
LD = /opt/product/ticm/build_tools/hp/gcc/gcc-3.4.6/bin/gcc
LDDLFLAGS = -shared

Both modules installed with 100% successful tests first time.

Thanks for taking the trouble to make some suggestions Tom.

I am one happy admin.

regards

Tony

> ----------------------------------------
> From: Tom Browder <tom.browder@gmail.com>
> Sent: Thu May 15 15:39:57 CEST 2008
> To: Anthony Kent <tonykent@bigfoot.com>
> Subject: Re: Unresolved symbol problem
> 
> 
> On 5/15/08, Anthony Kent <tonykent@bigfoot.com> wrote:
> > I have just tried the CPAN shell and unfortunately got exactly the same failure messages on the make test phase:
> ...
> > I suspect that the gcc library is not being found/declared properly, but I'm not sure how to prove this.
> 
> Try setting an environment variable to the desired gcc:
> 
> export CC='<path-to-gcc>'
> 
> And make sure LD_LIBRARY_PATH has the path to your locally-installed libs.
> 
> Then remake the module's Makefile.PL and retry the build.
> 
> -Tom
> 
> P.S.  Are you locked into that old gcc version?
> 
> P.P.S.  As administrator, you sure have some ugly paths on that
> host--that may be the source of some of the problems (later if not
> now) if there are years of old cruft hangin around--especially the way
> some Perl packages are cavalier about where modules are installed and
> how Perl's @INC is configured.

-----------------------------------------------------
Le bureau virtuel
http://www.lamessagerie.com

Re: Unresolved symbol problem

[Tom Browder]

On 5/15/08, Anthony Kent <tonykent@bigfoot.com> wrote:
> Tom,
>
> After 3 days of banging my head against brick walls I have found the solution! I am SO pleased.

Great!

Happy GNUing.

-Tom