Re: problem linking with shared library

2005-10-12 Thread Albert Chin
On Wed, Oct 12, 2005 at 01:56:39PM -0500, Nitesh Soni (NC/TNT) wrote: > Now I dont understand one basic thing: > > Since both static and shared library versions of libY have this > symbol as "U" when I link application X with static version it works > but not with shared. Also, point to be noted i

Re: linker cant locate a 3rd party lib

2005-10-12 Thread Jack Nguyen
LDFLAGS is already defined in my configure.ac. In fact i use it to do AC_CHECK_LIB(mkl,some_func). the problem is when i try to test my libfoo.la, it cant find the library it libfoo.la depends on. the console output is $libtool gcc -o test test.c libfoo.la gcc -o test test.c ./.libs/libfoo.a -L /sr

RE: problem linking with shared library

2005-10-12 Thread Nitesh Soni (NC/TNT)
Albert, I checked the source files of my libY. The symbol is declared extern. Now I dont understand one basic thing: Since both static and shared library versions of libY have this symbol as "U" when I link application X with static version it works but not with shared. Also, point to be noted i

Re: problem linking with shared library

2005-10-12 Thread Albert Chin
On Wed, Oct 12, 2005 at 01:03:12PM -0500, Nitesh Soni (NC/TNT) wrote: > The error linker is giving is: ... libY.so: undefined reference to > 'Z' > > Also, this symbol is not used anywhere in any source code required > to build application X ( i mean if X depends on x.c y.c z.c and > library libY .

RE: problem linking with shared library

2005-10-12 Thread Nitesh Soni (NC/TNT)
Albert Thanks for replying. The error linker is giving is: ... libY.so: undefined reference to 'Z' Also, this symbol is not used anywhere in any source code required to build application X ( i mean if X depends on x.c y.c z.c and library libY .. none of the sources x.c y.c and z.c use this sym

Re: problem linking with shared library

2005-10-12 Thread Albert Chin
On Wed, Oct 12, 2005 at 11:22:42AM -0500, Nitesh Soni (NC/TNT) wrote: > I am trying to build an executable "X" which links with libY. > > I am using libtool to build this library libY; so I have a static > version libY.a and libY.so > > When I link the static version libY.a, i am able to build th

problem linking with shared library

2005-10-12 Thread Nitesh Soni (NC/TNT)
Title: problem linking with shared library Hello all, I am trying to build an executable "X" which links with libY. I am using libtool to build this library libY; so I have a static version libY.a and libY.so When I link the static version libY.a, i am able to build the application X But

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Tim Mooney
In regard to: Re: mode=link and full path to dependent shared library?,...: On Wed, Oct 12, 2005 at 09:40:18AM -0500, Tim Mooney wrote: In regard to: Re: mode=link and full path to dependent shared library?,...: If so, shouldn't lib-link be producing that as deplib instead? I.e., aspell shou

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Albert Chin
On Wed, Oct 12, 2005 at 09:40:18AM -0500, Tim Mooney wrote: > In regard to: Re: mode=link and full path to dependent shared library?,...: > > > If so, shouldn't > >lib-link be producing that as deplib instead? I.e., aspell should be > >using the value of LTLIBINTL instead, I believe. > > I did n

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Albert Chin
On Tue, Oct 11, 2005 at 10:50:49PM +0200, Ralf Wildenhues wrote: > Hi Tim, Albert, > > * Tim Mooney wrote on Mon, Oct 10, 2005 at 10:27:11PM CEST: > > In regard to: Re: mode=link and full path to dependent shared library?,...: > > > > >>I'm talking about a situation like this: > > >> > > >>/bin/s

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Tim Mooney
In regard to: Re: mode=link and full path to dependent shared library?,...: Yes, it does. With your patch, there are no changes to output in the libtool test suite on Tru64 (so it didn't break anything that the tests catch), and libtool no longer removes /local/gnu/lib/libintl.so from the link

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Ralf Wildenhues
Me again, sorry. * Peter O'Gorman wrote on Wed, Oct 12, 2005 at 02:55:40PM CEST: > Ralf Wildenhues wrote: > > | Doesn't that patch break other libtool instances which do not have it? > | (i.e.: libfoo.la will contain `/path/to/libintl.so' in dependency_libs, > | but libtool's without your patch w

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Ralf Wildenhues
Hi Peter, Welcome back! :) * Peter O'Gorman wrote on Wed, Oct 12, 2005 at 02:55:40PM CEST: > Ralf Wildenhues wrote: > > | Doesn't that patch break other libtool instances which do not have it? > | (i.e.: libfoo.la will contain `/path/to/libintl.so' in dependency_libs, > | but libtool's without

Re: mode=link and full path to dependent shared library?

2005-10-12 Thread Peter O'Gorman
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues wrote: | Doesn't that patch break other libtool instances which do not have it? | (i.e.: libfoo.la will contain `/path/to/libintl.so' in dependency_libs, | but libtool's without your patch will refuse to read the .la file) | Untested