[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool and 32/64-bit builds
From: |
Albert Chin |
Subject: |
Re: libtool and 32/64-bit builds |
Date: |
Thu, 25 Jul 2002 15:14:28 -0500 |
User-agent: |
Mutt/1.2.5i |
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)