Re: libtool and 32/64-bit builds

[Albert Chin]

On Thu, Jul 25, 2002 at 02:47:56PM -0500, Bob Friesenhahn wrote:
> On Thu, 25 Jul 2002, Albert Chin wrote:
> 
> > Are you sure that [/64|/sparcv9] is added for user libraries?
> 
> I have verified (using gcc 3.1 with the -m64 option) that if
> -L/usr/local/lib is specified, the linker will use a 64-bit library
> located in /usr/local/lib/sparcv9 instead of a 32-bit library located
> in /usr/local/lib.

I'd be interested in looking at the truss output of this:
  $ truss -f -o /tmp/a [command]
  $ Mail address@hidden < /tmp/a

> > $ cc -xarch=v9 a.c -L/opt/TWWfsw/zlib11/lib -lz
> >         libz.so.1 =>     /usr/lib/64/libz.so.1
> >         libc.so.1 =>     /usr/lib/64/libc.so.1
> >         libdl.so.1 =>    /usr/lib/64/libdl.so.1
> >         /usr/platform/SUNW,Ultra-2/lib/sparcv9/libc_psr.so.1
> >
> > What do you make of this?
> 
> What I make of it is that you didn't specify a -R option to find the
> library, so ld.so looks in a system directory instead.  This has
> nothing to do with 32 vs 64 bit.

If -R was not included on the command-line, I should have received a
'(file not found)' string in the ldd output. Consider the following:

$ cc a.c -L/opt/TWWfsw/zlib11/lib -lz
$ ldd a.out
        libz.so.2 =>     (file not found)
        libc.so.1 =>     /usr/lib/libc.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        /usr/platform/SUNW,Ultra-2/lib/libc_psr.so.1

If ld "is" attaching the "/64", then I should get exactly the same
behaviour when building a 64-bit executable, but I don't.

I am not yet convinced that, for user libraries, ld appends the "/64".

-- 
albert chin (address@hidden)