Re: MacOSX module linking with static archive libtool problem

[Jonas Thiem]

This topic is rather old, and I'm referring to a particular post which 
can be found here:
http://www.mail-archive.com/address@hidden/msg03642.html
Obviously it isn't possible to link a static lib from a shared lib 
compiled in libtool as libtool blocks it (technically it would be 
possible on many, but not all platforms). This affects all platforms 
including Windows, not just Mac OS X.

Robert Boehne suggested some solutions to this:
> Suggestion 1, you could link to shared libraries rather than archives.
>Suggestion 2, if you're building it yourself, make the static libs
>convenience libraries, this will have the same effect as linking to 
static libs, but is portable.

This doesn't cover a special case though which I heard isn't *that* 
uncommon and which wasn't mentioned in the discussion at all:

Sometimes you create plugins/modules which refer back to functions in 
the main program.

On Unix, you can simply do this by unresolved symbols that get resolved 
to the main program itself at the point when it loads the shared libs. 
On Windows, where unresolved symbols aren't allowed, I am myself 
commonly generating a .a symbol file from the main program's symbols and 
linking it statically from my dlls, which works fine with mingw and also 
generates perfectly usable dlls.

Now with libtool this isn't possible. In my project, that led me to an 
ugly hack where I'm simply not using libtool for my modules at all when 
compiling for a windows target.

That's a rather unsatisfying solution. It works, but the condition in 
every Makefile.am of every module that contains both libtool code and 
manual code just for the windows platform to get it compiled seems 
rather ugly compared to a much simplier solution:

It could much easier be solved by libtool providing a switch to override 
the blocking of static linking out of shared libs. In my case, that also 
wouldn't impose a problem to Unix systems not supporting it, as I'd 
simply use it solely for the Windows platform where the .a link is 
needed to avoid unresolved symbols.

As the problem seems, after 6 years, still unresolved (if I'm wrong 
please correct me, I'm by no way an expert or even an advanced libtool 
user), it would be really great if such a flag got introduced: people 
may use or not use it depending on the target platforms they want to 
support, or they may even use it only through an optional condition for 
individual target platforms of which they know that they support static 
linking out of shared libs to achieve specific things - in my case 
avoidance of unresolved symbols.

This wouldn't cause a loss of compatibility for the average libtool user 
and provide a considerable amount of less pain in this specific special 
case.