On Sat, Dec 14, 2002 at 03:22:42AM -0600, Albert Chin wrote:
> Dependent libraries for hppa64* is funky.
>
> $ cd /tmp/a
> $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
> $ elfdump -L lib1.sl | head
> 0 Needed libc.2
> 1 Soname lib1.sl.0
> $ cd /tmp/b
> $ ld -b +h lib2.sl.0 -o li
Title: RE: hppa*64* and dependent libraries
Albert,
Post the patch you have for 1.4. I'm curious as to why you need to set $wl at all,
if linking is being done with "ld" then ${wl}="" for any flag. IMHO, if that
isn't being done properly we need to fi
On Wed, Dec 18, 2002 at 07:45:36PM -0500, Boehne, Robert wrote:
> Post the patch you have for 1.4. I'm curious as to why you need to
> set $wl at all, if linking is being done with "ld" then ${wl}="" for
> any flag. IMHO, if that isn't being done properly we need to find
> out why.
There's a sma
> Albert,
>
> Post the patch you have for 1.4. I'm curious as to why you need to set $wl
> at all,
> if linking is being done with "ld" then ${wl}="" for any flag. IMHO, if
> that
> isn't being done properly we need to find out why.
Just to add to the confusion, this is my original patch.
Dave
> Dependent libraries for hppa64* is funky.
>
> $ cd /tmp/a
> $ ld -b +h lib1.sl.0 -o lib1.sl obj1.o obj2.o -lc
> $ elfdump -L lib1.sl | head
> 0 Needed libc.2
> 1 Soname lib1.sl.0
> $ cd /tmp/b
> $ ld -b +h lib2.sl.0 -o lib2.sl ../a/lib1.sl obj3.o obj4.o -lc
> $ elfdump -L lib2.sl |
> I suggest neither. I believe that you don't want to try to hardcode
> the full path of libraries. It is better to use "+b" to set the embedded
> path. This is equivalent to the -rpath option when GNU ld is used.
The other way to set the embedded path is to use "-L" and "-l", and
NOT use "+b".
On Thu, Dec 19, 2002 at 12:45:55PM -0500, John David Anglin wrote:
> > ...
> >
> > We have two possible solutions:
> > (1) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a ../a/lib1.sl obj3.o obj4.o -lc
> > (2) ld -b +h lib2.sl.0 -o lib2.sl -L/tmp/a -l1 obj3.o obj4.o -lc
> >
> > I've confirmed the above
> I agree that we should use +b to embed the path. Is everyone else in
> agreement?
What about the alternative "-L" and "-l" approach which ia64 uses and
I adopted in my original patch? I tried to stay away from using "+b".
Maybe I am missing something but the package which I have built seem
to h
> /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
> pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
> pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
> pngwutil.o -L/opt/TWWfsw/zlib11/lib/pa20_64
> -L/opt/TWWfsw/zlib11/lib/pa20_64 -L/opt/TWWfsw
On Thu, Dec 19, 2002 at 03:13:13PM -0500, John David Anglin wrote:
> > I agree that we should use +b to embed the path. Is everyone else in
> > agreement?
>
> What about the alternative "-L" and "-l" approach which ia64 uses and
> I adopted in my original patch? I tried to stay away from using "+
On Thu, Dec 19, 2002 at 06:22:58PM -0500, John David Anglin wrote:
> > /usr/ccs/bin/ld -b +h libpng.sl.2 -o .libs/libpng.sl.2.2 png.o
> > pngerror.o pngget.o pngmem.o pngpread.o pngrio.o pngread.o pngrtran.o
> > pngrutil.o pngset.o pngtrans.o pngwio.o pngwrite.o pngwtran.o
> > pngwutil.o -L/opt/
> If I change the link line to the following (using libz.la rather than
> -L[path to zlib] -lz):
> ...
> /bin/sh ./libtool --mode=link cc +DD64 +O2 +ESlit +Onofltacc
> +Oentrysched +Odataprefetch +Onolimit -o libpng.la -rpath
> /opt/TWWfsw/libpng12/lib/pa20_64 -version-info 2:2:0 -module png.lo
>
12 matches
Mail list logo
