Most of the time upstream (myself included) just forgets to add a library at the end of the LDADD line, so all I had to do was send a trivial patch upstream to add "-lm" or something.
See here for an example: http://bugzilla-attachments.gnome.org/attachment.cgi?id=152993
In fact most of the changes will probably involve a one line addition.
As an example, galculator-1.3.4-2.fc12.src.rpm was found to be failing because libm is used but not explicitly linked.
RPM build errors: /usr/bin/ld.bfd: math_functions.o: undefined reference to symbol 'sin@@GLIBC_2.0' /usr/bin/ld.bfd: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line /lib/libm.so.6: could not read symbols: Invalid operation
The following would fix this and allow the package to build.
--- configure.in.old 2010-02-09 10:25:30.000000000 -0500 +++ configure.in 2010-02-09 10:26:28.000000000 -0500 @@ -16,6 +16,7 @@ PKG_CHECK_MODULES(PACKAGE, [$pkg_modules]) AC_SUBST(PACKAGE_CFLAGS) AC_SUBST(PACKAGE_LIBS) +AC_CHECK_LIB(m, pow)
GETTEXT_PACKAGE=galculator AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, "$GETTEXT_PACKAGE", [Name of gettext package])
There's an example at the bottom of the page : https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
demonstrating what a failed build message would look like, and how to go about fixing the issue.
On Tue, Feb 9, 2010 at 9:14 PM, Roland Grunberg rgrunber@redhat.com wrote:
Most of the time upstream (myself included) just forgets to add a library at the end of the LDADD line, so all I had to do was send a trivial patch upstream to add "-lm" or something.
See here for an example: http://bugzilla-attachments.gnome.org/attachment.cgi?id=152993
In fact most of the changes will probably involve a one line addition.
As an example, galculator-1.3.4-2.fc12.src.rpm was found to be failing because libm is used but not explicitly linked.
RPM build errors: /usr/bin/ld.bfd: math_functions.o: undefined reference to symbol 'sin@@GLIBC_2.0' /usr/bin/ld.bfd: note: 'sin@@GLIBC_2.0' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line /lib/libm.so.6: could not read symbols: Invalid operation
The following would fix this and allow the package to build.
--- configure.in.old 2010-02-09 10:25:30.000000000 -0500 +++ configure.in 2010-02-09 10:26:28.000000000 -0500 @@ -16,6 +16,7 @@ PKG_CHECK_MODULES(PACKAGE, [$pkg_modules]) AC_SUBST(PACKAGE_CFLAGS) AC_SUBST(PACKAGE_LIBS) +AC_CHECK_LIB(m, pow)
GETTEXT_PACKAGE=galculator AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, "$GETTEXT_PACKAGE", [Name of gettext package])
There's an example at the bottom of the page : https://fedoraproject.org/wiki/UnderstandingDSOLinkChange
demonstrating what a failed build message would look like, and how to go about fixing the issue.
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
Regards, Parag.
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS.
Jakub
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS.
I am not sure then what's wrong with my package. Here is how it failed http://koji.fedoraproject.org/koji/getfile?taskID=1970866&name=build.log and then modifying CFLAGS its successful build at http://kojipkgs.fedoraproject.org/packages/iok/1.3.9/1.fc13/data/logs/i686/b...
Parag.
On Tue, 9 Feb 2010 23:28:01 +0530, Parag wrote:
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS.
I am not sure then what's wrong with my package. Here is how it failed http://koji.fedoraproject.org/koji/getfile?taskID=1970866&name=build.log and then modifying CFLAGS its successful build at http://kojipkgs.fedoraproject.org/packages/iok/1.3.9/1.fc13/data/logs/i686/b...
Replace make CFLAGS="%{optflags} -X11" %{?_smp_mflags} with make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
Replace make CFLAGS="%{optflags} -X11" %{?_smp_mflags} with make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the upstream package so that it passes -lX11 where it needs it. The most proper change keeps -lX11 at the end of the link line, rather than the beginning.
Thanks, Roland
Hi, On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath roland@redhat.com wrote:
Replace make CFLAGS="%{optflags} -X11" %{?_smp_mflags} with make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the upstream package so that it passes -lX11 where it needs it. The most proper change keeps -lX11 at the end of the link line, rather than the beginning.
But, howcome build succeed with just adding -lX11 to CFLAGS for iok package?
Regards, Parag.
Hi, On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath roland@redhat.com wrote:
Replace make CFLAGS="%{optflags} -X11" %{?_smp_mflags} with make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the upstream package so that it passes -lX11 where it needs it. The most proper change keeps -lX11 at the end of the link line, rather than the beginning.
But, howcome build succeed with just adding -lX11 to CFLAGS for iok package?
I didn't say it wouldn't. "Ideal" means "ideal".
On Wed, 2010-02-10 at 10:20 -0800, Roland McGrath wrote:
Hi, On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath roland@redhat.com wrote:
Replace make CFLAGS="%{optflags} -X11" %{?_smp_mflags} with make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
This is still not really ideal. For the long run, you should be fixing the upstream package so that it passes -lX11 where it needs it. The most proper change keeps -lX11 at the end of the link line, rather than the beginning.
But, howcome build succeed with just adding -lX11 to CFLAGS for iok package?
I didn't say it wouldn't. "Ideal" means "ideal".
To answer the question, it works because the CFLAGS happen to be applied to the linker command as well as the LDFLAGS. As Roland says, though, adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the spec file is slightly less wrong, but having the upstream code add the flag properly during its configure stage is least wrong.
To answer the question, it works because the CFLAGS happen to be applied to the linker command as well as the LDFLAGS. As Roland says, though, adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the spec file is slightly less wrong, but having the upstream code add the flag properly during its configure stage is least wrong.
The main point of entirely pointless pedanticism I was making is that you really should put -lfoo at the end of a linking command line (after all the .o files), not at the beginning where ${LDFLAGS} usually goes.
For cases like this, it probably doesn't make a great deal of sense to use a configure test. That is, the call to some X11* function is not conditional in the source, so -lX11 need not be conditional in the makefile.
When there is no true need to conditionalize anything, extra autoconf and/or pkg-config magic just makes everything more arcane for no reason.
Thanks, Roland
On Wed, 2010-02-10 at 10:41 -0800, Roland McGrath wrote:
To answer the question, it works because the CFLAGS happen to be applied to the linker command as well as the LDFLAGS. As Roland says, though, adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the spec file is slightly less wrong, but having the upstream code add the flag properly during its configure stage is least wrong.
The main point of entirely pointless pedanticism I was making is that you really should put -lfoo at the end of a linking command line (after all the .o files), not at the beginning where ${LDFLAGS} usually goes.
Well, I'd say it's at least as important that the fix should be done in the appropriate place - the source code's configure step - and not wedged into the spec file. And then, of course, it should be sent upstream.
For cases like this, it probably doesn't make a great deal of sense to use a configure test. That is, the call to some X11* function is not conditional in the source, so -lX11 need not be conditional in the makefile.
When there is no true need to conditionalize anything, extra autoconf and/or pkg-config magic just makes everything more arcane for no reason.
The point of pkg-config isn't only (or even primarily) to conditionalize. It's more to abstract the name, location, dependencies and required flags of the library behind a single static thing (the pkg-config file). So the necessary flags - or anything else pkg-config provides - can be changed, if necessary, by the upstream project in a single place (the .pc file) and all downstreams will automatically inherit the change without having to touch anything. (If everything had been using pkg-config for 20 years, for instance, it's likely much less would be broken by this DSO change, because all the dependencies would be declared in the upstream pc files and downstream projects wouldn't have had a chance to forget about them :>)
Well, I'd say it's at least as important that the fix should be done in the appropriate place - the source code's configure step - and not wedged into the spec file. And then, of course, it should be sent upstream.
Absolutely!
Thanks, Roland
Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS.
I am not sure then what's wrong with my package. Here is how it failed http://koji.fedoraproject.org/koji/getfile?taskID=1970866&name=build.log
This build.log says: ---------------------------------------------------------------- /usr/bin/ld: keyevent.o: undefined reference to symbol 'XKeysymToString' /usr/bin/ld: note: 'XKeysymToString' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line /usr/lib/libX11.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status ---------------------------------------------------------------- And actually src/keyevent.c reads: ---------------------------------------------------------------- 275 if (key_disable_overwrite) { 276 key_event->keycode = -1; 277 key_event->keysym = 0; 278 g_print("Not allowed to overwrite KeyCode for %s", 279 XKeysymToString(keysym)); 280 return; 281 } ----------------------------------------------------------------
You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in, for example.
and then modifying CFLAGS its successful build at http://kojipkgs.fedoraproject.org/packages/iok/1.3.9/1.fc13/data/logs/i686/b...
Parag.
Regards, Mamoru
On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS.
I am not sure then what's wrong with my package. Here is how it failed http://koji.fedoraproject.org/koji/getfile?taskID=1970866&name=build.log
This build.log says:
/usr/bin/ld: keyevent.o: undefined reference to symbol 'XKeysymToString' /usr/bin/ld: note: 'XKeysymToString' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line /usr/lib/libX11.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status
And actually src/keyevent.c reads:
275 if (key_disable_overwrite) { 276 key_event->keycode = -1; 277 key_event->keysym = 0; 278 g_print("Not allowed to overwrite KeyCode for %s", 279 XKeysymToString(keysym)); 280 return; 281 }
You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in, for example.
BTW, while you touch this package, it would be useful to fix up all the warnings, I can't believe doing e.g. strcmp on an array of wchar_t can be right. It seems with the exception of one wmemset only strcpy/strcmp etc. are used on keyvalue, so probably keyvalue just should be char array instead of wchar_t, but you'll need to figure out the right size. E.g. having [1] sized keyname can't be right when you copy in 1 char long strings and use strcmp on it afterwards.
Jakub
Hi,
On Wed, Feb 10, 2010 at 5:27 PM, Jakub Jelinek jakub@redhat.com wrote:
On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek jakub@redhat.com wrote:
On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for now.
They don't belong to CFLAGS, those are flags for compilation. You want LDFLAGS or even better add it in configure to LIBS.
I am not sure then what's wrong with my package. Here is how it failed http://koji.fedoraproject.org/koji/getfile?taskID=1970866&name=build.log
This build.log says:
/usr/bin/ld: keyevent.o: undefined reference to symbol 'XKeysymToString' /usr/bin/ld: note: 'XKeysymToString' is defined in DSO /usr/lib/libX11.so.6 so try adding it to the linker command line /usr/lib/libX11.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status
And actually src/keyevent.c reads:
275 if (key_disable_overwrite) { 276 key_event->keycode = -1; 277 key_event->keysym = 0; 278 g_print("Not allowed to overwrite KeyCode for %s", 279 XKeysymToString(keysym)); 280 return; 281 }
You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in, for example.
BTW, while you touch this package, it would be useful to fix up all the warnings, I can't believe doing e.g. strcmp on an array of wchar_t can be right. It seems with the exception of one wmemset only strcpy/strcmp etc. are used on keyvalue, so probably keyvalue just should be char array instead of wchar_t, but you'll need to figure out the right size. E.g. having [1] sized keyname can't be right when you copy in 1 char long strings and use strcmp on it afterwards.
Thanks Mamoru and Jakub for your feedback. I will get that code updated soon.
Regards, Parag.
On Wed, 2010-02-10 at 20:42 +0900, Mamoru Tasaka wrote:
You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in, for example.
It's nicer to use pkg-config for libraries which provide .pc files, isn't it? X11 does:
/usr/lib64/pkgconfig/x11.pc
On Wed, 2010-02-10 at 10:34 -0800, Adam Williamson wrote:
On Wed, 2010-02-10 at 20:42 +0900, Mamoru Tasaka wrote:
You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in, for example.
It's nicer to use pkg-config for libraries which provide .pc files, isn't it? X11 does:
/usr/lib64/pkgconfig/x11.pc
Yes. If you do
PKG_CHECK_MODULES(FOO, x11)
then FOO_LIBS and FOO_CFLAGS will be defined to the appropriate libraries and cflags for libX11. The second argument can be a list:
PKG_CHECK_MODULES(FOO, x11 xext sm)
will add the right things for all of libX11, libXext, and libSM.
- ajax
-
Adam Jackson -
Adam Williamson -
Jakub Jelinek -
Mamoru Tasaka -
Michael Schwendt -
Parag Nemade -
Roland Grunberg -
Roland McGrath