libtool
[Top][All Lists]
Advanced

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

RE: global_symbol_pipe not picking up an initialized globalvariable with


From: Duft Markus
Subject: RE: global_symbol_pipe not picking up an initialized globalvariable with msvc
Date: Tue, 18 Aug 2009 10:38:34 +0200

> 
> > > UTL_EXPORT becomes __declspec(dllexport) when compiling
> > > the shared lib, __declspec(dllimport) when compiling the
> > > executable that uses it.
> >
> > did you double check if that really works on both sides?
> > your problem sound to me as if dllimport is missing
> > somewhere.
> 
> Not enough.  I checked this once more and the dllimport was missing.
> When I
> jimmy around the definition of UTL_EXPORT, I can make this problem
> disappear.  When UTL_EXPORT is empty I get this error.  When it's
> defined as
> __declspec(dllimport), utils-test links fine.
> 
> > shouldn't that be looking for __imp_optopt, etc? i guess
> > you do try to link against a shared lib?
> 
> When I'm linking against a shared lib, this works.  If I'm linking
> against a
> static lib, UTL_EXPORT needs to be empty or I get errors like this:
> 
> unresolved external symbol __imp__optopt
> 
> There's another thread about how to define UTL_EXPORT properly so I'll
> respond there about how to handle this.  It feels like I want a
> compiler
> flag to depend on the kind of library found at link
time...problematic.

Thats exactly one of the reasons why i started out with parity [1]. it's
sole purpose is to ease building windows binaries using the native
visual studio compiler, but still behaving a little more like gcc/other
unixish compilers/linkers. with parity it's easy: define dllimport
_always_, and the compiler will handle the case where the library is
built static only - so both versions work without the target binary
needing to know which linking it has to use.

parity also has tons of other features, like LD_PRELOAD, lazy loading,
etc. some documentation can be found in it's subversion repo, accessible
through sourceforge. maybe that helps. there is a libtool patch too,
which makes the two work together perfectly... however (harrumph @ ralf
;) ) more than two years of reporting the patch didn't bring it into
libtools repo(s).

[1] http://www.sf.net/projects/parity

Have fun :)
Cheers, Markus

> 
> Thanks for your help.
> 
> -DB





reply via email to

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