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

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

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:
> >
> > http://lists.gnu.org/archive/html/libtool/2003-01/msg00060.html
>
>
> 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.

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'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 gpm-h.in 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?

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/