Sun 10 Feb 2008 04:01:28 PM UTC, comment #11:
aclocal and autoconf is enough. Well, I guess I can live with that.
|
Sun 10 Feb 2008 03:59:56 PM UTC, comment #10:
You are right, I'm using debian boxes to make the tarballs. I'm afraid you'll have to regenerate aclocal, configure, Makefile.in and others when packaging , see comment #7.
|
Sat 09 Feb 2008 11:44:25 AM UTC, comment #9:
Looks like 0.8.6 and 0.8.7 were also spun using Debian autotools. I did investigate the issue further, and found what was causing the rpath killer to break the build, patch attached. Please note that I have absolutely no idea what it does, I just used my analytical skills :)
(file #15006)
|
Tue 18 Sep 2007 08:23:29 AM UTC, comment #8:
Seems it is a fedora build issue more that a gchempaint bug.
|
Tue 18 Sep 2007 05:20:40 AM UTC, comment #7:
Seems you used the configure.ac from cvs too (version=0.8.4). The libtool file is generated at configure time from files installed by libtoolize (and probably aclocal). If my version of libtool is an issue in fedora, you'll have to use autogen.sh (or the commands herein) each time you build a new version.
IMHO, you should just copy the appropriate lines to your script, i.e.:
aclocal
libtoolize --force
intltoolize --force
gnome-doc-prepare --force
autoheader
automake --gnu -af
autoconf
gentoo does such thing for many packages, so I believe it is the right way to go.
|
Mon 17 Sep 2007 08:50:30 PM UTC, comment #6:
Funky... running the autogen.sh script myself remedied the issue. I don't get one thing now: libtool is generated at configure stage, so what is causing the difference? diff attached.
(file #13976)
|
Mon 17 Sep 2007 08:36:14 PM UTC, comment #5:
I did not change anything in the code itself, but the packages were generated with other versions of the autotools and libtool, most probably, dur to a migration from gentoo to debian.
|
Mon 17 Sep 2007 08:22:49 PM UTC, comment #4:
I will try. Did you change the toolchain you used to roll up the release?
|
Mon 17 Sep 2007 08:20:36 PM UTC, comment #3:
Seems it really comes from libtool. Try running autogen.sh from the cvs repository before configure so that you'll use the fedora libtool.
|
Mon 17 Sep 2007 08:06:35 PM UTC, comment #2:
The Makefile.am files did not change since 0.8.2, so this is quite strange. No rpath used directly, may be through libtool?
|
Mon 17 Sep 2007 03:56:55 PM UTC, comment #1:
More info. It certainly has something to do with the used kludge, as disabling it make s the build work. It did not hurt the previous versions, though. The rpath ban is explained here:
http://fedoraproject.org/wiki/Packaging/Guidelines?highlight=%28DIE_RPATH_DIE%29#head-a1dfb5f46bf4098841e31a75d833e6e1b3e72544
|
Mon 17 Sep 2007 03:23:13 PM UTC, original submission:
Hi. In the process of upgrading fedora package to 0.8.3, I hit the following error:
usr/bin/ld: warning: libgcpcanvas-0.8.3.so, needed by ../lib/.libs/libgchempaint.so, not found (try using -rpath or -rpath-link)
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_line_ext_get_type'
../lib/.libs/libgchempaint.so: undefined reference to `gcp_pango_layout_replace_text'
../lib/.libs/libgchempaint.so: undefined reference to `g_printable_export_svg'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_pango_get_cur_index'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_group_ext_get_type'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_rect_ext_get_type'
../lib/.libs/libgchempaint.so: undefined reference to `g_printable_get_type'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_bpath_ext_get_type'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_pango_set_selection_bounds'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_ellipse_ext_get_type'
../lib/.libs/libgchempaint.so: undefined reference to `gnome_canvas_pango_get_type'
collect2: ld returned 1 exit status
make[2]: *** [gchempaint] Error 1
make[2]: Leaving directory `/home/jsikorski/rpmbuild/BUILD/gchempaint-0.8.3/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/jsikorski/rpmbuild/BUILD/gchempaint-0.8.3'
make: *** [all] Error 2
Due to the fact that rpath use is forbidden in the fedora packages, I use the following workaround:
sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool
sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool
It has always worked, 0.8.3 is the first version that fails. libgcpcanvas-0.8.3.so is present in libgcpcanvas/.libs so it's unlikely a race condition caused by a parallel build.
|