(as AT for g/fbsd) tring to install gimp 2.4: Calculating dependencies ..... ..... done! [ebuild N ] media-gfx/gimp-2.4.0_rc1 USE="dbus jpeg lcms mmx png sse svg tiff -aalib (-alsa) (-altivec) -curl -debug -doc -gnome -gtkhtml -mng -pdf -python -smp -wmf" 0 kB i get this error: (cd .libs && rm -f libgimpthumb-2.0.la && ln -s ../libgimpthumb-2.0.la libgimpthumb-2.0.la) i686-gentoo-freebsd6.2-gcc -march=athlon64 -pipe -O2 -mfpmath=sse -msse2 -Wall -Wdeclaration-after-statement -Wmissing-prototypes -Wmissing-declarations -Winit-self -Wpointer-arith -Wl,-O1 -o .libs/gimp-thumbnail-list gimp-thumbnail-list.o ./.libs/libgimpthumb-2.0.so /var/tmp/portage/media-gfx/gimp-2.4.0_rc1/work/gimp-2.4.0-rc1/libgimpmath/.libs/libgimpmath-2.0.so -L/usr/lib /usr/lib/libgthread-2.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so /usr/lib/libintl.so /usr/lib/libiconv.so /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_destroy' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_create' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_init' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_exit' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_equal' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_getschedparam' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_setscope' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_setschedparam' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_setstacksize' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_setschedparam' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_setdetachstate' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_join' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_cond_timedwait' /usr/lib/libgthread-2.0.so: undefined reference to `pthread_attr_getschedparam' collect2: ld returned 1 exit status gmake[2]: *** [gimp-thumbnail-list] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 * * ERROR: media-gfx/gimp-2.4.0_rc1 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_compile * ebuild.sh, line 990: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * gimp-2.4.0_rc1.ebuild, line 99: Called die * * emake failed * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/media-gfx/gimp-2.4.0_rc1/temp/build.log'. Reproducible: Always
Created attachment 129466 [details] build.log
Try: emerge -1 dev-libs/glib
Created attachment 129484 [details, diff] gimp-2.4.0_rc1.ebuild.patch seem that gaim fails the main compilation on g/fbsd because some modules are not linked against -pthread during the final binary linkage. this patch is a temporarily fix that globaly append "-lpthread" to LDFLAGS, letting people at least compile and use gimp until a real solution will be provided. (as AT i have sucessful tested the patch both on g/linux and g/fbsd)
(In reply to comment #2) > Try: > emerge -1 dev-libs/glib > tried, but nothing changed. libgthread-2.0.so seem correctly linked against -pthread, so the problem is arount gimp linkage process.
(In reply to comment #3) > gimp-2.4.0_rc1.ebuild.patch This patch is generally correct, but it is prepared for wrong package. The problem is with /usr/lib/libgthread-2.0.so with belongs to dev-libs/glib, so the similar patch should be applied to dev-libs/glib, not to media-gfx/gimp.
roy@uberlaptop ~ $ pkg-config --libs glib -lglib roy@uberlaptop ~ $ pkg-config --libs glib-2.0 -lglib-2.0 -lintl -liconv roy@uberlaptop ~ $ pkg-config --libs gthread -lgthread -lpthread -lglib roy@uberlaptop ~ $ pkg-config --libs gthread-2.0 -pthread -lgthread-2.0 -lglib-2.0 -lintl -liconv This shows that the glib package is already built correctly and exposes the correct libraries to link with. The issue is that gimp is using glib but not querying gthread even though it's linking to it, therefor gimp needs to be fixed and not glib.
Created attachment 129628 [details, diff] Swap -pthread for -lpthread like Linux Hmmmmm. Seems that we need the same -lpthread hack that upstream added for Linux with gcc-3 even though we're using gcc-4. Test this patch against glib-2, then try and re-emerge gimp.
Yeah, that fixes it. CC'ing gnome and hanno for their view on this.
I've no bsd, so don't count on me, but if someone from the bsd-team says it works, I'll add it. Have you communicated with upstream? As it's rc-time, it's probably wise to get this fixed before 2.4 final.
(In reply to comment #9) > Have you communicated with upstream? As it's rc-time, it's probably wise to > get this fixed before 2.4 final. It's rc-time for GIMP, but this patch seems to be for GLib.
It IS for glib. It seems bugzie lost the comment I made a while back. GNOME team, want a new bug for glib or is this good enough?
Looks harmless for linux-based systems, I vote ok to commit. Is there an open bug in gnome's bugzilla for glib and/or gimp? Daniel, thoughts?
(In reply to comment #12) > Looks harmless for linux-based systems, I vote ok to commit. Is there an open > bug in gnome's bugzilla for glib and/or gimp? There is now http://bugzilla.gnome.org/show_bug.cgi?id=475619
Created attachment 130982 [details, diff] libtool should allow -pthread in deplibs This could also be viewed as a libtool error. Debian, FreeBSD, NetBSD and OpenBSD all ship libtools with a similar patch to this. Infact, libXrender (and more and more ebuilds) ships with a libtool with a similar patch again, which causes KDE libtool to barf as it doesn't understand -pthread in the deplibs - thankfully newer ones do. See bug #182214 for this. My preference would be to fix libtool and add this patch to elibtoolize as other ebuilds would benefit as we force -pthread on them in similar situations.
Created attachment 131003 [details, diff] libtool should allow -pthread in deplibs Heh, wrong patch.
Upstream went with the 1st patch.
and that is included in glib-2.14.1. Do we need to patch 2.12?
Not unless you plan on keeping 2.14.1 in package.mask for any amount of time :)
Unmasked.
Should we leave this open, and assign it to base-system to get libtool fixed?
Nah, we'll close this for now. libtool upstream ARE aware of the issue but don't know how to solve it as it "exposes libtool bugs" and agree that it's a problem for distro's. At least that's how I read their mailing list archive. All the more reason to ditch libtool and use pkg-config imo.
