[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 20:17:49 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MultiZilla/

Gerrit P. Haase wrote:

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.

You're missing the point. *libtool* doesn't know that -DPIC means nothing for your code. On some platforms, you really have to compile DIFFERENT CODE, not just compile the same code in a different way (-fpic), when you want to make a pic object.

So Libtool is merely supplying a compile define as a hint, that you can then use in your code:

#if PIC
  this stuff is pic-safe
  do it some other way

It's no different than in the bad old days, when libtool gave us DLL_EXPORT:

  #define decoration declspec(__dllexport__)
  #define decoration declspec(__dllimport__)

It was up to the client code to cooperate with the -DDLL_EXPORT symbol; to use it in the right way; to not use it in ways that didn't work with libtool, etc.

Same with -DPIC.  gmp attempts to do that, but is going about it wrong IMO.

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.

See above. Libtool is providing a symbol that COULD, even on cygwin, be of some use. You cannot specify it as an AM_CFLAGS because it should be "on" when building .lo's and "off" when building .o's -- and AM_CFLAGS don't allow that fine-grain control. So libtool does it.

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

It is not used by gmp. It might be used by ncurses. Or Orbit. Or any one of the thousands of other libtoolized packages. You're asking me to unilaterally remove a feature from libtool that other packages may already be using, because gmp doesn't use it and gets confused by it?

That's a gmp bug, not a libtool bug.

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.

The buildtool is not broken. It's providing a hint to the package(gmp in this case). It's not libtool's fault that gmp doesn't properly interpret that hint on cygwin; gmp DOES interpret the hint properly on other platforms ["properly" == compiles the correct code]. And gmp already has a workaround to adapt its own funkiness to work with libtool on cygwin. Gmp's workaround is


(translation: on most platforms, obey -DPIC. if PIC undef, compile non-pic asm instructions; if PIC def, compile the other instructions. BUT, if DLL_EXPORT (e.g. if cygwin|mingw)) then gmp should always compile the non-pic asm instructions. This is a gmp-specific exception; other packages may, even on cygwin, unlike gmp, want to behave differently when -DPIC/-UPIC.

But, because DLL_EXPORT does not mean "platform == cygwin|mingw", we need to change this gmp-specific workaround to one that is actually correct:

if (eq(`PLATFORM',`cygwin'),`undefine(`PIC')')

(I'm sure my syntax is wrong, but you get the idea)

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

Yes, I know.  That aspect of Bruno's code annoys me to no end.

Of course, you're defeating your own argument here. Why should I change the "official cygwin" libtool, or push changes upstream to the "real" libtool, to fix gmp -- when Bruno won't use the stock version anyway?


reply via email to

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