On Sun, 28 Jun 2009, Charles Wilson wrote:
Interesting. I think that it is assumed that "PIC" code will work in a
static archive. Apparently this is a wrong assumption for "decorated"
DLL code. Most open source projects ported to Windows rely on GCC's
automatic DLL import feature.
Unless yo
Bob Friesenhahn wrote:
> On Sun, 28 Jun 2009, Charles Wilson wrote:
>>
>> So, when we get around to linking the actually installable library, both
>> the DLL and the "static' archive contain the same .o's -- the ones
>> compiled with the "pic" flags -DDLL_EXPORT and -DPIC.
>>
>> This is a problem,
On Sun, 28 Jun 2009, Charles Wilson wrote:
So, when we get around to linking the actually installable library, both
the DLL and the "static' archive contain the same .o's -- the ones
compiled with the "pic" flags -DDLL_EXPORT and -DPIC.
This is a problem, because now the "static" archive contai
I ran in to a problem using libtool to generate both shared and static
libraries with convenience archives (on cygwin, but I believe this is
cross-platform). Working with git-master xz utils, with some local
patches, I saw the following:
/bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99
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 comp
Hello Charles,
* Charles Wilson wrote on Sun, Jun 28, 2009 at 12:54:59AM CEST:
> The best I could come up with is this: IN the source code for the object, do
>
> - top of file -
> #if defined(BUILDING_MY_LIBRARY) && defined(DLL_EXPORT)
> stuff
> #endif
> - end of file -
>
> This
