On Jul 26, 2000, Mo DeJong <[EMAIL PROTECTED]> wrote:
> If the error said "libtool can not link a static library into
> the shared library you are trying to create" then I would
> agree with you. The existing warning does not tell me that.
Please suggest a better wording.
> Why is it a warning? This should be an error. If I tell it
> "use -lgdi32" it should use it or error out.
Nope. -lgdi32 is being recorded as a required dependency, and it will
be linked in when any executables or other libraries are linked with
the library you're creating. From the abstract point of view of
libtool archives, whether you get a dynamic library or an ordinary
archive is irrelevant. If you play by the rules, it shouldn't make
any difference.
But I understand this all breaks down on MS-Windows, in which object
files created for dynamic libraries are completely different from
those created for static libraries. I don't know how to solve this
problem. We need some way for the build process to figure out in
advance whether it'll be able to generate the shared library with a
given set of dependency libraries, so that it can pass the appropriate
flags to the compiler. Gee, DLLs suck :-(
> I gave up on libtool and just switched to autoconf + automake
> with the ld -shared option and it is working just fine
> (the linking of a static lib into a .dll that is).
If you care about keeping using libtool, maybe -Wl,-lthestaticlib will
work for now. Libtool won't realize it's a dependency, but it may
work.
I wonder whether the symbols imported from a static library into a DLL
are re-exported, and how data symbols work in this case.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
