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