Re: [ autogen-Bugs-1045642 ] libtool/cygwin build failure
Hello, I tried myself to build autogen on Cygwin, however it is nearly impossible. The whole build system is somewhat messed up. I consider: install all the latest versions of the autotools, automake-1.9.latest, autoconf 2.59, libtool 1.5.10 and then simply run `autoreconf --install --verbose --force' Fix all the issues which prevent autoreconf to terminate without error and it will build on Cygwin. Gerrit ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Ping: Cygwin libtool / assembler problem with -DPIC
Hi Charles, I just don't think it is good idea to use flags for s.th. else just because they are there anywhere. If there is need for anther special flag then introduce it, exactly for this reason and this platform and for nothing else. DLL_EXPORT is the best example, if there is really a need for another flag like this to be used like you described then introduce one which is a flag that doesn't affect other tools like ld, as, ar, PIC is the option to get position independent code where it makes a difference. It makes no difference on Cygwin: so don't use the flag. Gerrit -- =^..^= ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Ping: Cygwin libtool / assembler problem with -DPIC
Charles Wilson wrote: That's a gmp bug, not a libtool bug. And I don't think so. IMO all assembler code cannot be compiled on Cygwin when you use -DPIC to compile it. If libtool is used as it is now, the compilation will fail, so libntool should care about this and don't use this flag in case platform is Cygwin and compiling assembler code. Gerrit -- =^..^= ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Ping: Cygwin libtool / assembler problem with -DPIC
Hi Charles, yet another contra: 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. Don't mix things up. `-f' is a command line switch for gcc/ld/whatever, `-D' defines a macro and is not a command line switch to any tool. You can think of it as counterpart of a `#define PIC 1' in any included header and doesn't affect the behaviour of gcc/ld/whatever. So IMO -D is completely in the user domain, just like CFLAGS, ASFLAGS et al. If libtool needs a flag internally to distinguish between shared a non shared code compilation, then use another one, e.g. LT_DO_LO_NOW? 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. IMO the only relevant and also the only used flag on platforms where it is needed is -fPIC? 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? Yes. Well, what I'm really asking for is to make libtool better, i.e. do s.th. about the fact that a defined PIC macro breaks assembler code e.g. to disable the macro automatically when assembler code is to be compiled with libtool. Gerrit -- =^..^= http://nyckelpiga.de/donate.html ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
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 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). 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. Gerrit -- =^..^= http://nyckelpiga.de/donate.html ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Ping: Cygwin libtool / assembler problem with -DPIC
Noah Misch wrote: On Tue, Oct 12, 2004 at 03:29:10PM +0200, Gerrit P. Haase wrote: Gerrit wrote: PING! Hello, With GNU as PIC is not an noop, when -DPIC is used to invoke gas the generated assembly is broken. I saw this problem with a reautoconfiscated version of GMP. This may be unusual, but there was libtool used to invoke gas. What do you mean by ``the generated assembly is broken''? Please show the error you encountered. I built gmp-4.1.4 on Cygwin, and it passed all tests. I used the shipped ``configure'', but adding -DPIC is not a new libtool behavior. 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. Gerrit -- =^..^= ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
[BUG] checking if gcc supports -fno-rtti -fno-exceptions... no
Hallo, I use gcc-3.3 and see this output since I upgraded the compiler: $ gcc -fno-rtti -fno-exceptions conftest.c -o conftest.o cc1: warning: -frtti is valid for C++ but not for C/ObjC which leads to this statement in the configure run: checking if gcc supports -fno-rtti -fno-exceptions... no Why is gcc and not g++ tested with these flags? And if you test to compile C++ code with gcc than you should test with conftest.cc or some file that is treated as C++ input by gcc and not with conftest.c. Regards, Gerrit -- =^..^= ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: How to disable relink on install?
Hallo Alex, I'm using libtool 1.4.2 on a redhat 8.0 machine and when do a make install in my project libtool relinks all my libs and binaries. How can I disable this? I never run my binaries from the build area, only from the installed prefix. Linking a large C++ binary takes a long time, so I'd like to avoid doing it twice I use libtool on Cygwin. Usually no relinking is needed on Cygwin/Windows. So I open and edit every .la file in question and remove the relink command at the bottom before I run `make install`. Gerrit -- =^..^= ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
