Re: Detecting Static/Shared builds

[Jason Curl]

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?

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.

Regards,
Jason.
> Jason Curl wrote:
>   
> > Hello,
> >
> > I've set up a library that can be built on Windows (mingw32 or cygwin)
> > or on a Unix type OS (e.g. Linux or Solaris). I've defined a header that
> > checks if the WINDOWS_H file exists and if it does, I then define things
> > like LIBAPI, WINAPI, DLLEXPORT.
> >
> > That all works when I build a shared library.
> >
> > But when I build a static library that will link with the executables
> > (primarily to make debugging easier), on Windows platforms I have
> > problems because LIBAPI is still defined decl(dllexport) and it doesn't
> > need to be.
> >
> > Is there anyway from the libtool system to know if the current file
> > being compiled is for static or shared, maybe through a #define? I've
> > skimmed through the libtool manual but not found anything terribly
> > relevant except for section 5.6 (Static-only libraries).
> >
> > But I believe this problem can occur even if I build both, then I need
> > to figure out which invocation (shared or static) and so a variable in
> > configure.ac won't work either, probably something passed on the command
> > line.
> >
> > Of course, it's only a problem on Windows (my main platform).
> >
> > It might be I use a compiler other than GNU (e.g. Intel, or MSVC) so I'd
> > like to avoid compiler specific features, but I'll always be using
> > autoconf and friends.
> >
> > Thanks,
> > Jason.
> >