Configure bombs out if it finds wrong-architecture libraries

[p5pRT]

Migrated from rt.perl.org#100992 (status was 'open')

Searchable as RT100992$

[p5pRT]

From @nwc10

Created by @nwc10

On this Sparc Linux system, if I try to build 64 bit with this​:

./Configure -Dusedevel=y -Dcc=ccache\ gcc -Dld=gcc -Dcf_email='nick@​ccl4.org' -Dperladmin='nick@​ccl4.org' -Doptimize=-g -Duse64bitall -Dprefix=~/Sandpit/snap5.9.x-$patch -Accflags=-m64 -Aldflags=-m64 -Alddlflags='-m64'

[ie adding -m64 to cc, ld and lddl flags], it bombs out in Configure​:

I used the command​:

  ccache gcc -o try -g -m64 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -m64 -fstack-protector -L/usr/local/lib try.c -lnsl -ldb -ldl -lm -lcrypt -lutil -lc
  ./try

and I got the following output​:

/usr/bin/ld​: skipping incompatible /usr/lib/gcc/sparc-linux-gnu/4.3.2/../../../libdb.so when searching for -ldb
/usr/bin/ld​: skipping incompatible /usr/lib/gcc/sparc-linux-gnu/4.3.2/../../../libdb.a when searching for -ldb
/usr/bin/ld​: skipping incompatible /usr/bin/../lib/libdb.so when searching for -ldb
/usr/bin/ld​: skipping incompatible /usr/bin/../lib/libdb.a when searching for -ldb
/usr/bin/ld​: skipping incompatible /usr/lib/libdb.so when searching for -ldb
/usr/bin/ld​: skipping incompatible /usr/lib/libdb.a when searching for -ldb
/usr/bin/ld​: cannot find -ldb
collect2​: ld returned 1 exit status
I can't compile the test program.
(The supplied flags or libraries might be incorrect.)

The problem, I think, is that it's *still* searching in /usr/lib etc
(the 32 bit library directories) and anything it finds there, it thinks is
fair game. This isn't a problem if parallel 64 bit versions are installed,
but all goes badly wrong if they aren't.

I *think* that hints/linux.sh isn't perfect either, in that to find the
library paths it invokes gcc with just -print-search-dirs. However, gcc's
library search varies depending on the architecture flags. ie​:

$ /usr/bin/gcc -print-search-dirs | grep libraries | cut -f2- -d= | tr '​:' '\n' | grep -v 'gcc' | sed -e 's​:/$​::'
/lib/sparc-linux-gnu/4.3.2
/lib/../lib
/usr/lib/sparc-linux-gnu/4.3.2
/usr/lib/../lib
/lib
/usr/lib
$ /usr/bin/gcc -m64 -print-search-dirs | grep libraries | cut -f2- -d= | tr '​:' '\n' | grep -v 'gcc' | sed -e 's​:/$​::'/lib/sparc-linux-gnu/4.3.2/64
/lib/../lib64
/usr/lib/sparc-linux-gnu/4.3.2/64
/usr/lib/../lib64
/lib/sparc-linux-gnu/4.3.2
/lib
/usr/lib/sparc-linux-gnu/4.3.2
/usr/lib

I *think* that we'd be more correct to pass the compiler flags to that gcc
invocation (or at least, the -m flags). However, in this case it turns out
even that won't help. Filtering for directories that exist​:

$ for file in `/usr/bin/gcc -print-search-dirs | grep libraries | cut -f2- -d= | tr '​:' '\n' | grep -v 'gcc' | sed -e 's​:/$​::'`; do test -e $file && ls -ld $file; done
drwxr-xr-x 12 root root 12288 Apr 12 08​:43 /lib/../lib
drwxr-xr-x 74 root root 36864 Aug 18 00​:06 /usr/lib/../lib
drwxr-xr-x 12 root root 12288 Apr 12 08​:43 /lib
drwxr-xr-x 74 root root 36864 Aug 18 00​:06 /usr/lib
$ for file in `/usr/bin/gcc -m64 -print-search-dirs | grep libraries | cut -f2- -d= | tr '​:' '\n' | grep -v 'gcc' | sed -e 's​:/$​::'`; do test -e $file && ls -ld $file; done
drwxr-xr-x 2 root root 4096 Apr 12 08​:42 /lib/../lib64
drwxr-xr-x 4 root root 4096 Apr 12 08​:45 /usr/lib/../lib64
drwxr-xr-x 12 root root 12288 Apr 12 08​:43 /lib
drwxr-xr-x 74 root root 36864 Aug 18 00​:06 /usr/lib

And filtering those for libdb.so
$ for file in `/usr/bin/gcc -print-search-dirs | grep libraries | cut -f2- -d= | tr '​:' '\n' | grep -v 'gcc' | sed -e 's​:/$​::'`; do test -f $file/libdb.*so && file -L $file/libdb.*so; done
/usr/lib/../lib/libdb.so​: ELF 32-bit MSB shared object, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked, stripped
/usr/lib/libdb.so​: ELF 32-bit MSB shared object, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked, stripped
$ for file in `/usr/bin/gcc -m64 -print-search-dirs | grep libraries | cut -f2- -d= | tr '​:' '\n' | grep -v 'gcc' | sed -e 's​:/$​::'`; do test -f $file/libdb.*so && file -L $file/libdb.*so; done
/usr/lib/libdb.so​: ELF 32-bit MSB shared object, SPARC32PLUS, V8+ Required, version 1 (SYSV), dynamically linked, stripped

ie it would *still* find the 32 bit libdb.so, and then choke on it.

The only way I can get Configure to complete is to force the library path
with -Dlibpth=/lib64\ /usr/lib64

In addition, to get the build to complete, I need to manually add -shared
to lddlflags. ie, if I just -Alddflags=-m64, whatever adds -shared doesn't.
That's probably a separate bug.

I'm not sure what the correct fix for this is. Possibly, Configure's
ordering should actually be​:

1​: Determine compiler flags
2​: Use compiler flags to determine library search path
3​: For each prospective library found in the search path, actually try to
  link with it.

which by Configure's standards, is a radical change from what it currently
does, isn't it?

Nicholas Clark

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.15.3:

Configured by nick at Sun Oct  9 16:01:49 CEST 2011.

Summary of my perl5 (revision 5 version 15 subversion 3) configuration:
  Derived from: b2ef48712a32b5d1bf0f3519e431413fc7285b7c
  Platform:
    osname=linux, osvers=2.6.26-2-sparc64-smp, archname=sparc64-linux
    uname='linux grobluk 2.6.26-2-sparc64-smp #1 smp thu jan 27 03:27:39 utc 2011 sparc64 gnulinux '
    config_args='-Dusedevel=y -Dcc=ccache gcc -Dld=gcc [email protected] [email protected] -Doptimize=-g -Duse64bitall -Dprefix=~/Sandpit/snap5.9.x-v5.15.3-326-gb2ef487 -Accflags=-m64 -Aldflags=-m64 -Alddlflags=-m64 -shared -Dlibpth=/lib64 /usr/lib64 -de'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='ccache gcc', ccflags ='-m64 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-g',
    cppflags='-m64 -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.3.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -m64 -fstack-protector'
    libpth=/lib64 /usr/lib64
    libs=-lnsl -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.7.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.7'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags=' -fPIC', lddlflags=' -m64 -shared -fstack-protector'

Locally applied patches:
    


@INC for perl 5.15.3:
    lib
    /home/nick/Sandpit/snap5.9.x-v5.15.3-326-gb2ef487/lib/perl5/site_perl/5.15.3/sparc64-linux
    /home/nick/Sandpit/snap5.9.x-v5.15.3-326-gb2ef487/lib/perl5/site_perl/5.15.3
    /home/nick/Sandpit/snap5.9.x-v5.15.3-326-gb2ef487/lib/perl5/5.15.3/sparc64-linux
    /home/nick/Sandpit/snap5.9.x-v5.15.3-326-gb2ef487/lib/perl5/5.15.3
    .


Environment for perl 5.15.3:
    HOME=/home/nick
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/bash

[p5pRT]

From @nwc10

On Sun, Oct 09, 2011 at 09​:17​:57AM -0700, Nicholas Clark wrote​:

The problem, I think, is that it's *still* searching in /usr/lib etc
(the 32 bit library directories) and anything it finds there, it thinks is
fair game. This isn't a problem if parallel 64 bit versions are installed,
but all goes badly wrong if they aren't.

I should add that I think I had the analogous problem on OS X building with
-m32. Configure would find libgdbm.so, and hence enable building GDBM_File.
Problem was that only a 64 bit version was actually installed. It's not just
a Linux issue.

But I tried building with -m32 today and I don't have this problem any more.
I'm guessing that something caused macports to rebuild libgdbm.dylib with
+universal, as it now has "both"* architectures.

Nicholas Clark

* There have only ever been 2 architectures, x86_64 and i386. Honest.
  Never ppc or ppc64. (Let alone m68k, albeit not for OS X)

[p5pRT]

From @jkeenan

On Sun, 09 Oct 2011 16​:17​:57 GMT, nicholas wrote​:

./Configure gurus​: Is this approach, suggested by Nicholas lo these many years ago, worth exploring?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @arc

James E Keenan via RT <perlbug-followup@​perl.org> wrote​:

./Configure gurus​: Is this approach, suggested by Nicholas lo these many years ago, worth exploring?

Well, I'd consider it a portability issue rather than specifically a
Configure one, but yes, I'm inclined to think it'd be worth exploring.
The scale of the changes required means that it probably isn't a good
thing to try out at this stage of the release cycle, though.

--
Aaron Crane ** http​://aaroncrane.co.uk/

[toddr]

Is this still something we want to pursue? I'm not sure what the state of Sparc Linux is.