[Top][All Lists]

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

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

From: Charles Wilson
Subject: Re: Ping: Cygwin libtool / assembler problem with -DPIC
Date: Thu, 14 Oct 2004 03:17:57 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MultiZilla/

Gerrit P. Haase wrote:

Noah Misch wrote:
There was a thread about this general topic awhile ago. That GMP actively uses
-DPIC to select the correct assembly came up:

I saw that -DPIC was used on Cygwin to compile assembly and it couldn't be
linked.  Also I read in the GMP sources somewhere that libtool adds this
flag where it is a noop on Cygwin when not compiling assembler code where
it breaks things, so the conclusion was to remove the flag entirely when
platform is Cygwin, I was able to build GMP and thats it.

Unfortunately I have no logs, but I tracked it down and realized that
this flag is the culprit and removing it resolves my problem.  Even
more bad that the demo I suspect to show the error doesn't build at all
with the recent Cygwin release (demos/expr).

Anyway, this flag is used where it is completely useless, so please
remove it, patch was already submitted to the Cygwin libtool maintainer.

Okay, I looked at the x86-defs.m4 file in the gmp distro. It turns out that they specifically say:

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.


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'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.

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).

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?


reply via email to

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