[Top][All Lists]
[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