[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
> > =>     /usr/lib/64/
> > =>     /usr/lib/64/
> > =>    /usr/lib/64/
> >         /usr/platform/SUNW,Ultra-2/lib/sparcv9/
> >
> > 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 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 =>     (file not found) =>     /usr/lib/ =>    /usr/lib/

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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]