Re: Link error for blahS.c when used in multiple GCC environment.

[Brendon Costa]

I think i am starting to understand the problem a little bit more. I
will explain in detail what i think is going on. Please look at this and
let me know if you think this is a bug/limitation in libtool or not.


I have the following elements in the project:

libmystatic:
        A static library of C++ code. I am forcing this to be static for
demonstration purposes using the -static flag. Because it is C++ it also
should have a dependency against libstdc++

libmyshared:
        Another library that is a standard libtool library. On my platform it
is generally used as a shared library as NetBSD along with many other
platforms supports shared libraries. Because it is C++ it also should
have a dependency against libstdc++

myplugin:
        This is a libtool plugin module declared with the -module flag. This
plugin uses code from libmystatic so it lists in its LIBADD a reference
to libmystatic. This is also a C++ module but has a few extern "C"
functions used in the interface for dlopening. This plugin module would
also have a dependency on libstdc++

library_user:
        Is an application that uses code directly from libmystatic, libmyshared
and DLOpens the plugin module myplugin. So this application links with
the two libraries. I also added a -dlopen myplugin.la reference to this
applications LDADD and also added a reference to the
LTDL_SET_PRELOADED_SYMBOLS() macro in its main so that it can still use
myplugin on platforms that dont support DLOpening modules natively. So
this also makes use of libltdl. Because it is C++ it also should have a
dependency against libstdc++

The error described in an earlier email (Undefined symbol link errors
for symbols in libstdc++ while linking library_user application) occurs
in the above described configuration.


If i change ANY of the following then it will compile/link fine:

1) Remove support for dl-preopening by removing the -dlopen flags and
the macro from the library_user's main function.

2) Remove the code from myplugin that references libmystatic and remove
libmystatic from the linking dependencies of myplugin so that myplugin
does not depend in any way on libmystatic

3) Do not force libmystatic to be a static library but get it to create
a shared library and so myplugin links against a shared version of it
instead of using it as a static library.


I am not very familiar with libtool, so please tell me if i am on the
wrong track here...

I think that when libtool looks at myplugin to obtain the list of
symbols to put into the pre-loaded symbol (Even though the pre-opening
is not currently being used), it finds the symbols for libstdc++ as they
have been imported into myplugin because it linked with libmystatic.

Is this desired behavior?
I.e. should it only get the symbols defined in myplugin that were not
imported from other libraries or is it standard for the symbols exported
in myplugin including those from libmystatic to be exported for the
preloading symbol list? (I am not sure if it is even possible to filter
this out anyway).


Also...
Is it possible that libtool is looking at the incorrect installed
version of libstdc++ in order to construct the preloading symbol list?
I.e. It looks at myplugin, sees that myplugin depends on libstdc++
because it was linked with libmystatic and then goes to libstdc++ to
find the symbols but is looking at the incorrect library instance?


Thanks,
Brendon.





Brendon Costa wrote:
> Ralf Wildenhues wrote:
>> * Brendon Costa wrote on Tue, Apr 03, 2007 at 12:21:05AM CEST:
>>> They are both C++ libraries yes. I do not tell either of them to link
>>> with libstdc++ explicitly. The linking lines for the libs are below.
>> Libtool gets the libstdc++ part in, for g++.
>>
>>> There is no mention of libstdc++ in the linking of libmystatic. There is
>>> however a reference to libstdc++ while linking libmyshared which is
>>> added in by libtool. This should be normal behavior shouldn't it?
>> I guess.  I meant: why do you have one static and one shared C++
>> library?  What is the need?
>>
> 
> I don't need it as such. This is a demonstration project that
> demonstrates using various linking methods and how that affects the
> usage of my analysis tool.
> 
> I assumed creating a static library was possible and that the
> resulting library could then be used like any other static library on
> the system. I could always change it to a convenience library which i
> assume would not suffer from this problem, but it would be good to get
> to the bottom of this problem.
> 
> There are probably a lot of other users out there that are doing this
> that have not come across the problem because they are using a single
> compiler. I really need to find a resolution to the problem otherwise
> they will not be able to use my tool unless they also change to
> convenience libraries which may not be what they want.
> 
> 
>> I guess I need to dig out whether such a setup is supported by GCC.
>> If it is, then it seems we have a Libtool limitation here.
>>
> 
> I am sorry i don't understand what you mean by whether such a setup is
> supported by GCC.
> 
> I will try and compile the project manually without libtool and see if
> i can get it to work. That might give more of an indication of where
> the problem might be.
> 
> Thanks for looking into it. I appreciate the help.
> Brendon.
> 
>> Thanks,
>> Ralf
>>
>>
> 
> 
> 
> 
>