libtool
[Top][All Lists]
Advanced

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

Re: Detecting Static/Shared builds


From: Markus Duft
Subject: Re: Detecting Static/Shared builds
Date: Mon, 07 Sep 2009 10:34:44 +0200
User-agent: Thunderbird 2.0.0.22 (X11/20090831)

> Message: 2
> Date: Sun, 06 Sep 2009 17:34:39 +0200
> From: Jason Curl <address@hidden>
> Subject: Re: Detecting Static/Shared builds
> To: Monty Taylor <address@hidden>,    Bob Friesenhahn
>       <address@hidden>
> Cc: address@hidden
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Monty Taylor wrote:
>> In my builds, libtool is doing:
>>
>>  -fPIC -DPIC
>>
>> Which would mean you should be able to do:
>>
>> #ifdef PIC
>>
>> or the like. From reading the libtool.m4 file, it looks like it will not
>> add -DPIC if you are using djgpp.
>>
>> Monty
>>   
> This doesn't sound very friendly at all! libtool exports DLL_EXPORT from 
> what I can tell, only when I'm building Win32 DLL. I can't see if 
> anything is defined when either importing, or building the library when 
> static.
> 
> So great, I can figure out when I need to use __declspec(dllexport). But 
> I don't know when I should use __declspec(import) or nothing (e.g. 
> importing from a DLL or using a static lib respectively).
> 
> Any other ideas?

The main problem is, that the _executable_ can never know for shure,
wether -DPIC was given on the command line while building the _library_.

You may be interested in parity [1], which manages all this. With parity
(which is a wrapper around visual c++), you can _akways_ do
__declspec(dllimport) (and never dllexport), and things will work in all
static/shared combinations. Parity also plays nice with libtool, if you
apply a patch.

If you have questions, you're welcome.

[1] http://sourceforge.net/projects/parity/

Cheers, Markus

> 
> I thought about a macro in Makefile.am to know when I'm building, but 
> the program importing the library then needs to know. Sounds like 
> something that would then be best in the ".la" file that libtool knows 
> about.
> 
[snip]




reply via email to

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