On 9/24/2010 2:53 PM, Ralf Wildenhues wrote: >> Den 2010-09-24 19:30 skrev Charles Wilson: >>> That is the typical approach. The drawback -- usually an acceptable one >>> -- is that if you are building a "stack" of dependent DLLs: >>> >>> EXE --> C.DLL -> B.DLL >>> --> A.DLL >>> >>> Then (a) you must link exe using .obj's compiled as pic (e.g. with >>> -DDLL_EXPORT, even tho the EXE *itself* is not a "shared library"). >>> libtool does this by default IIRC. > > Huh? But automake won't go this way usually. With > > bin_PROGRAMS = foo > foo_SOURCES = foo.c > foo_LDADD = libc.la > > foo will be linked with foo.o (*not* created by libtool), and neither > foo.lo nor .libs/foo.o will ever be created.
Err...maybe you are right. I've been so used to auto-import (and now, even the warnings are suppressed with modern cygwin and mingw gcc/binutils), that I'm just used to it simply working. If I understand the process, the above would fail if libc.la had a shared library, but we linked foo using -disable-auto-import (e.g. or we were talking about MSVC.) More in my reply to Peter's message. -- Chuck
