This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ping: Cygwin libtool / assembler problem with -DPIC

Hi Charles,

> Libtool gives -DPIC -DDLL_EXPORT to indicate a cygwin or mingw DLL. We
> undefine PIC since we don't need to be position independent in this
> case and definitely don't want the ELF style _GLOBAL_OFFSET_TABLE_ etc.

> ifdef(`DLL_EXPORT',`undefine(`PIC')')

> Now, on *mingw*, we do indeed (up to now) define both DLL_EXPORT and PIC
> which compiling .lo's.  However, for cygwin, we no longer define 
> DLL_EXPORT, but continue to define PIC.  So the little rule above is 
> ineffective, and gmp ends up compiling the wrong assembler code.

Now I see, thanks.

> Now, I'd call this a case -- maybe -- of gmp assuming too much about the
> internals of libtool.  OTOH, libtool emitting -Dcodes means that those
> codes are supposed to be USED, right?

> I'm not convinced that it is a BAD thing to emit a -Dcode indicating 
> when a source file is being compiled for a shared object, even when just
> considering cygwin alone.  I can see cases where one might want to 
> implement something differently within a shared lib vs. a static lib. 
> If we unilaterally remove -DPIC on cygwin, we can never do anything like
> that.

I think it is a bad thing to add -D flags unconditionally and for sure
it is a bad thing if it is a noop.

> What gmp is doing is using the fact that "-DDLL_EXPORT" is defined to 
> indicate that the target platform is cygwin or mingw.  It does this 
> because gmp "knows" that it DOESN'T want to use the special PIC-guarded
> code on cygwin|mingw, *even* when building .lo's on those platforms. 
> (The fun part is specifically says libtool's DLL_EXPORT is NOT
> used.  Errr...bzzt.  Yes it is!)

> However, DLL_EXPORT is an unreliable platform indicator, as we've 
> obviously seen here; it's only true when building .lo's on mingw now. 
> But I don't think just turning -DDLL_EXPORT back on for cygwin is the 
> answer, either.  (I don't really remember when this stopped being on for
> cygwin, but whatever).

The answer should be to not define -D flags which do nothing, let the
user decide which -D flags she wants, these are CFLAGS after all.

> I think gmp's x86-defs.m4 needs to use $host (or whatever analogue it 
> can conjure up) to determine when the platform is cygwin or mingw, and
> use THAT to decide when to undefine PIC.

> Gerrit, if you change the line in x86-defs.m4 to ALWAYS undefine PIC, 
> does that fix your build problem even when libtool still -DPIC's?  If 
> so, then certainly we can come up with a better way for gmp's config.m4
> machinery to determine its target platform, right?

Should do it, yes, however, why not undefine it in libtool, I still
don't see the reason why it is used at all.

And yes, GMP should not care that much about its own machinery, if there
is a flag in libtool that prevents generating working code then
obviously the used tool is broken and should be fixed, defining these
workarounds because buildtools are broken is not the way to go.  Because
Haible's packages nearly always include hacked versions of libtool or m4
macros it is always a pita to apply newer libtool versions, i.e. simply
doing autoreconf fails in most of the cases (CLN, gettext, libiconv,
GMP, ...choose your favourite Haible package...).

I don't whine if all works as expected, but in case of GMP it is even
impossible to build the vanilla source with the C++ lib included.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]