Re: -no-undefined vs gcc 4.6.0
On Sat, 19 Mar 2011, LRN wrote: On 19.03.2011 0:17, Vincent Torri wrote: On Sat, 19 Mar 2011, LRN wrote: On 18.03.2011 23:51, Vincent Torri wrote: On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. It's not my library. I'm compiling mpc-0.8.2 ok. Anyway you have to pass -Wl,-no-undefined. It's an option for the linker [1], not for gcc [2] Vincent Torri [1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld [2] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options I *know* that it's a linker option. And i know that i have to pass it with -Wl because of that. What i do not know is how to make libtool see it when it is passed like that. Finally got it to work with `make libmpc_la_LDFLAGS=-version-info 2:0:0 -no-undefined', because mpc does not use AM_LDFLAGS in the link command that i'm wondering if you ever read my first answer... Vincent is used to build libmpc (mpc devs are probably the ones to blame, but right now i just want to make it work). Although i've found no way to pass such an option with spaces to `make' from a variable expansion (i.e. `make $opts'), so i've had to hard-code it into make invocation instead. I expect to find a lot of libtool-using projects that will require such hacks or workarounds, because `unrecognized option '-no-undefined'' is very common. ___ http://lists.gnu.org/mailman/listinfo/libtool ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On 3/19/2011 6:25 AM, LRN wrote: I expect to find a lot of libtool-using projects that will require such hacks or workarounds, because `unrecognized option '-no-undefined'' is very common. Ah, but actually -no-undefined should be added by the upstream maintainers, in Makefile.am, to libfoo_la_LDFLAGS. It is a *description* of the library -- which is true regardless of the host platform the library is being built for. It is a claim by the library designer that: This library, when linked, will not reference any symbols, unless they are defined either in its own source objects or in other explicitly listed dependencies In order to build a library on win32/cygwin, libtool requires that the library designer assure it of this fact. So, either a library DOES or DOES NOT satisfy the claim: if it doesn't, then it can't be built on windows without massive surgery. If it does, then it does no harm to tell ALL platforms that it does so -- thus, upstream should add -no-undefined to their Makefile.am/libfoo_la_LDFLAGS. This declaration is usually NOT passed via an explicit variable statement on the make or configure command line. -- Chuck ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. Vincent ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On 18.03.2011 23:51, Vincent Torri wrote: On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. It's not my library. I'm compiling mpc-0.8.2 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: -no-undefined vs gcc 4.6.0
On Sat, 19 Mar 2011, LRN wrote: On 18.03.2011 23:51, Vincent Torri wrote: On Fri, 18 Mar 2011, LRN wrote: Since gcc 4.6.0 it is no longer possible to use LDFLAGS=-no-undefined gcc now says something like this: gcc.exe: error: unrecognized option '-no-undefined' Before 4.6.0 it was possible to do that, and gcc said only this: gcc.exe: unrecognized option '-no-undefined' That is, unrecognized option was not considered a show-stopper, and everything worked just fine - the option, being part of LDFLAGS, eventually reached libtool, and libtool were taking the clue to disallow undefined symbols. Not anymore. Now i have to pass LDFLAGS=-Wl,-no-undefined. Which is ok from gcc' point of view, but libtool is unable to recognize this argument in such form and simply refuses to build shared libraries outright. Not sure if it's a bug or a feature, and how to work through that without making groundbreaking changes in software packages that use libtool. I think that you have to pass -no-undefined to the ***_LDFLAGS variable of your library: lib_LTLIBRARIES = libproject.la libproject_la_LDFLAGS = -no-undefined or, globally: AM_LDFLAGS = -no-undefined it has always worked for me, without gcc warning. It's not my library. I'm compiling mpc-0.8.2 ok. Anyway you have to pass -Wl,-no-undefined. It's an option for the linker [1], not for gcc [2] Vincent Torri [1] http://unixhelp.ed.ac.uk/CGI/man-cgi?ld [2] http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#Link-Options ___ http://lists.gnu.org/mailman/listinfo/libtool