Hi,
i am working on a review of guayadeque https://bugzilla.redhat.com/show_bug.cgi?id=853553 since serveral month.
my question is: how is the best way to handle this particular wx lib using cmake. Can someone with more knowledge suggest a solution.
Ivan the reviewer[mailto:drizt@land.ru] didn't respond on any questions... he continues to insist that pkgconfig is the right way to do it.
thanks Martin
On Sat, 22 Dec 2012 16:51:25 +0100 (CET), Martin Gansser wrote:
i am working on a review of guayadeque https://bugzilla.redhat.com/show_bug.cgi?id=853553 since serveral month.
my question is: how is the best way to handle this particular wx lib using cmake. Can someone with more knowledge suggest a solution.
Ivan the reviewer[mailto:drizt@land.ru] didn't respond on any questions... he continues to insist that pkgconfig is the right way to do it.
Part of this is due to language barriers and because you could have asked Ivan early to quote/attach unified patches.
Comment 40 of the ticket suggests that there exist helper methods for CMake to query pkgconfig. That sounds just fine, provided that wxsqlite3-devel included a working pkgconfig file, but it does not. Check this out:
$ rpm -q wxsqlite3-devel wxsqlite3-devel-3.0.1-1.fc18.x86_64 $ rpmls wxsqlite3-devel|grep pc -rw-r--r-- /usr/lib64/pkgconfig/wxsqlite3.pc $ pkg-config --exists wxsqlite3 || echo "no" no
Just to demonstrate that it fails. Let's see why while still using pkg-config instead of displaying the .pc file directly:
$ pkg-config --libs wxsqlite3 Package wxGTK-devel was not found in the pkg-config search path. Perhaps you should add the directory containing `wxGTK-devel.pc' to the PKG_CONFIG_PATH environment variable Package 'wxGTK-devel', required by 'wxsqlite3', not found
Oh! wxGTK-devel is an RPM package name, not a pkgconfig template name. That doesn't work. The "Requires" dependencies in .pc files are pkgconfig dependencies, not RPM dependencies.
$ grep ^Req /usr/lib64/pkgconfig/wxsqlite3.pc Requires: wxGTK-devel sqlite-devel
Same mistake for sqlite-devel. Does wxGTK-devel include a .pc file you could depend on? The one for sqlite-devel is named "sqlite3":
$ rpmls sqlite-devel|grep pkg -rw-r--r-- /usr/lib64/pkgconfig/sqlite3.pc
However, wxsqlite3 is linked with libsqlite already, so it shouldn't be necessary to depend on sqlite3.pc. Unless the dep is needed for the pkg-config --cflags query (i.e. if wxsqlite3 headers include sqlite3 headers).
Primary objective should be to fix wxsqlite3.pc, so that you can query it with pkgconfig.
Gesendet: Samstag, 22. Dezember 2012 um 21:19 Uhr Von: "Michael Schwendt" mschwendt@gmail.com An: packaging@lists.fedoraproject.org Betreff: Re: [Fedora-packaging] guayadeque pkgconfig question On Sat, 22 Dec 2012 16:51:25 +0100 (CET), Martin Gansser wrote:
i am working on a review of guayadeque https://bugzilla.redhat.com/show_bug.cgi?id=853553 since serveral month.
my question is: how is the best way to handle this particular wx lib using cmake. Can someone with more knowledge suggest a solution.
Ivan the reviewer[mailto:drizt@land.ru] didn't respond on any questions... he continues to insist that pkgconfig is the right way to do it.
Part of this is due to language barriers and because you could have asked Ivan early to quote/attach unified patches.
Comment 40 of the ticket suggests that there exist helper methods for CMake to query pkgconfig. That sounds just fine, provided that wxsqlite3-devel included a working pkgconfig file, but it does not. Check this out:
$ rpm -q wxsqlite3-devel wxsqlite3-devel-3.0.1-1.fc18.x86_64 $ rpmls wxsqlite3-devel|grep pc -rw-r--r-- /usr/lib64/pkgconfig/wxsqlite3.pc $ pkg-config --exists wxsqlite3 || echo "no" no
Just to demonstrate that it fails. Let's see why while still using pkg-config instead of displaying the .pc file directly:
$ pkg-config --libs wxsqlite3 Package wxGTK-devel was not found in the pkg-config search path. Perhaps you should add the directory containing `wxGTK-devel.pc' to the PKG_CONFIG_PATH environment variable Package 'wxGTK-devel', required by 'wxsqlite3', not found
Oh! wxGTK-devel is an RPM package name, not a pkgconfig template name. That doesn't work. The "Requires" dependencies in .pc files are pkgconfig dependencies, not RPM dependencies.
$ grep ^Req /usr/lib64/pkgconfig/wxsqlite3.pc Requires: wxGTK-devel sqlite-devel
Same mistake for sqlite-devel. Does wxGTK-devel include a .pc file you could depend on? The one for sqlite-devel is named "sqlite3":
$ rpmls sqlite-devel|grep pkg -rw-r--r-- /usr/lib64/pkgconfig/sqlite3.pc
However, wxsqlite3 is linked with libsqlite already, so it shouldn't be necessary to depend on sqlite3.pc. Unless the dep is needed for the pkg-config --cflags query (i.e. if wxsqlite3 headers include sqlite3 headers).
Primary objective should be to fix wxsqlite3.pc, so that you can query it with pkgconfig. --
Michael thanks for the detailed explanation. I hope that I have understood everything correct. I proceed now to your instructions and have modified the file wxsqlite3.pc. Now it looks like this:
prefix=/usr libdir=/usr/lib64 WXSQLITE_MINOR_VERSION=2.8 includedir=/usr/include
Name: wxsqlite3 Description: C++ wrapper around the SQLite 3.x database URL: http://wxcode.sourceforge.net/components/wxsqlite3/ Version: 3.0.1 Requires: Libs: -L${libdir} -lwxcode_gtk2u_wxsqlite3-${WXSQLITE_MINOR_VERSION} -lgdk_pixbuf-2.0 Cflags: -I${includedir}/wx
pkg-config --libs wxsqlite3 gives now the following:
-lwxcode_gtk2u_wxsqlite3-2.8 -lgdk_pixbuf-2.0
finally the link loader had issued the following message:
/bin/ld: CMakeFiles/guayadeque.dir/iPodMedia.o: undefined reference to symbol 'gdk_pixbuf_save_to_buffer' /bin/ld: note: 'gdk_pixbuf_save_to_buffer' is defined in DSO /lib64/libgdk_pixbuf-2.0.so.0 so try adding it to the linker command line /lib64/libgdk_pixbuf-2.0.so.0: could not read symbols: Invalid operation
then I added also the option-lgdk_pixbuf-2.0 to the wxsqlite3.pc.
If you have no objection, I would report the changes on wxsqlite3.pc upstream.
Martin
On Sun, 23 Dec 2012 00:02:17 +0100 (CET), Martin Gansser wrote:
prefix=/usr libdir=/usr/lib64 WXSQLITE_MINOR_VERSION=2.8
If this value is needed only in one place, isn't a variable overhead and reduces readability? Rather I would make your wxsqlite3 spec file substitute the minor version in the .pc file (e.g. using "sed -i") when creating it.
Libs: -L${libdir} -lwxcode_gtk2u_wxsqlite3-${WXSQLITE_MINOR_VERSION} -lgdk_pixbuf-2.0
The -L${libdir} is ignored, since default libdir is a standard search path.
pkg-config --libs wxsqlite3 gives now the following:
-lwxcode_gtk2u_wxsqlite3-2.8 -lgdk_pixbuf-2.0
Why would linking with wxsqlite3 strictly require linking with gdk-pixbuf2? wxsqlite3 is linked with that library already, btw. The .pc file would be incomplete, too, because of its empty Requires line => no dep on gdk-pixbuf-2.0
finally the link loader had issued the following message:
/bin/ld: CMakeFiles/guayadeque.dir/iPodMedia.o: undefined reference to symbol 'gdk_pixbuf_save_to_buffer' /bin/ld: note: 'gdk_pixbuf_save_to_buffer' is defined in DSO /lib64/libgdk_pixbuf-2.0.so.0 so try adding it to the linker command line /lib64/libgdk_pixbuf-2.0.so.0: could not read symbols: Invalid operation
The full output for the gcc/ld invocation would be relevant here to examine the linker options.
If something in guayadeque fails to link because it needs libgdk_pixbuf2, it becomes necessary to find out where to fix it, not just add it blindly to wxsqlite3.
guayadeque's src/iPodMedia.cpp accesses the gdk-pixbuf API, for example. => wxsqlite3 is the wrong place where to link the missing lib
Gesendet: Sonntag, 23. Dezember 2012 um 11:10 Uhr Von: "Michael Schwendt" mschwendt@gmail.com An: packaging@lists.fedoraproject.org Betreff: Re: [Fedora-packaging] guayadeque pkgconfig question On Sun, 23 Dec 2012 00:02:17 +0100 (CET), Martin Gansser wrote:
prefix=/usr libdir=/usr/lib64 WXSQLITE_MINOR_VERSION=2.8
If this value is needed only in one place, isn't a variable overhead and reduces readability? Rather I would make your wxsqlite3 spec file substitute the minor version in the .pc file (e.g. using "sed -i") when creating it.
Libs: -L${libdir} -lwxcode_gtk2u_wxsqlite3-${WXSQLITE_MINOR_VERSION} -lgdk_pixbuf-2.0
The -L${libdir} is ignored, since default libdir is a standard search path.
pkg-config --libs wxsqlite3 gives now the following:
-lwxcode_gtk2u_wxsqlite3-2.8 -lgdk_pixbuf-2.0
Why would linking with wxsqlite3 strictly require linking with gdk-pixbuf2? wxsqlite3 is linked with that library already, btw. The .pc file would be incomplete, too, because of its empty Requires line => no dep on gdk-pixbuf-2.0
the file /usr/lib64/pkgconfig/wxsqlite3.pc looks now as following and work for the compilation. Is this ok now ?, then i will submit a new wxsqlite3.pc file upstream.
prefix=/usr libdir=/usr/lib64 includedir=/usr/include
Name: wxsqlite3 Description: C++ wrapper around the SQLite 3.x database URL: http://wxcode.sourceforge.net/components/wxsqlite3/ Version: 3.0.1
Libs: -L${libdir} -lwxcode_gtk2u_wxsqlite3-2.8 Cflags: -I${includedir}/wx
finally the link loader had issued the following message:
/bin/ld: CMakeFiles/guayadeque.dir/iPodMedia.o: undefined reference to symbol 'gdk_pixbuf_save_to_buffer' /bin/ld: note: 'gdk_pixbuf_save_to_buffer' is defined in DSO /lib64/libgdk_pixbuf-2.0.so.0 so try adding it to the linker command line /lib64/libgdk_pixbuf-2.0.so.0: could not read symbols: Invalid operation
The full output for the gcc/ld invocation would be relevant here to examine the linker options.
If something in guayadeque fails to link because it needs libgdk_pixbuf2, it becomes necessary to find out where to fix it, not just add it blindly to wxsqlite3.
guayadeque's src/iPodMedia.cpp accesses the gdk-pixbuf API, for example. => wxsqlite3 is the wrong place where to link the missing lib
I need to investigate further
packaging@lists.fedoraproject.org
-
Martin Gansser -
Michael Schwendt