libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Different object lists for static and shared libraries


From: Charles Wilson
Subject: Re: Different object lists for static and shared libraries
Date: Sun, 28 Jun 2009 13:57:29 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.6.666

Ralf Wildenhues wrote:
> * Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST:
>> Is there a better way?
> 
> Not that I know of.  The current code might cause the object list for
> the static library to be a larger set than that for the shared library
> (because it won't add objects compiled with -static/--tag=disable-shared
> to $non_pic_objects), but not vice versa; but my guess is that was only
> done to avoid relocation errors.
> 
> With a suitably smart linker, your approach shouldn't cause a larger
> final shared library product, however.

Well, as it happens windres does not like empty files.

So, I hacked up this approach:

%.lo : %.rc
        $(LTRCCOMPILE) -i $< -o $@
        $(COMPILE) -x c -c $< -o $(*D)/$(*F).o

where the second line forces to recreate the "static" .o by using gcc to
compile it as a C file (without -DRC_INVOKED), where the .rc source
looks like:

#if defined(RC_INVOKED)
stuff
#endif

Since automake doesn't yet put rules for .rc files into Makefile.in, I
had to do it manually anyway -- so the hack above is not TOO bad.

Anyway, it seems to do the right thing.  However...now I have noticed a
different problem related to creating both static and shared libraries
from (the same) convenience archives.  I'll start a new thread.

--
Chuck




reply via email to

[Prev in Thread] Current Thread [Next in Thread]