I've emerged last -9999 babl, gegl and libmypaint, but gimp-9999 stil fails at the end, this time reporting some TLS-related troubles. It appears that during icon installation gegl is used in a way that makes it puke. It seems that it and its modules use TLS and that gegl now and then spawns a new thread from dl-opened module, which reserves TLS, but since it was compiled with static-tls model, linker has to know at link time how much space to reserve and sooner or later this runs out. It seems similar to this: http://stackoverflow.com/questions/19268293/matlab-error-cannot-open-with-static-tls key line in log file seems to match: "load error: dlopen: cannot load any more object with static TLS" I've attached full log file. Reproducible: Always Steps to Reproduce: 1.emerge "=media-gfx/gimp-9999" 2. 3.
Created attachment 426228 [details] emerge log file
Hi! Funky :) If I am not mistaken, we have a Gegl issue here that affects Gimp compilation, not a Gimp thing by itself. A minimal working example seems to be: git clone --depth 1 git://git.gnome.org/gimp cd gimp/icons/Symbolic/ mkdir 12 /usr/bin/gegl-0.3 -x "<gegl> <node operation='gegl:invert-gamma'></node> <node operation='gegl:load'> <params> <param name='path'>../../icons/Symbolic/12/gimp-zoom-follow-window.png</param> </params> </node> </gegl>" -o 12/gimp-zoom-follow-window.png With Gegl 0.3.4 these succeed over here. No results for Gegl 9999 yet. Have you played with GCC parameter -ftls-model on gegl, already?
(In reply to Sebastian Pipping from comment #2) > With Gegl 0.3.4 these succeed over here. No results for Gegl 9999 yet. With both Gegl and Babl on 9999 built today, the call to Gegl still succeeds for me. Could you share the output of * portageq envvar CFLAGS LDFLAGS * gcc -dumpversion ? Thanks!
portageq envvar CFLAGS LDFLAGS: -march=native -O3 -pipe -fdiagnostics-color=auto -Wl,-O3 -Wl,--sort-common -Wl,--as-needed those are global C|LD|FLAGS I compiled {babl,gegl} with several FLAG versions, LTO and non-LTO, always with same result. I tried also using gcc-4.9.3 - with the same result. I ended up back on gcc-5.3.0 and recompiled both with -O2 with USE="debug" for gegl. Same result. After running your testcase with GEGL_DEBUG=all, I get: GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:631: Platform Name: Clover GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:632: Version: OpenCL 1.1 MESA 11.1.2 GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:633: Extensions: cl_khr_icd GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:634: Default Device Name: AMD BARTS (DRM 2.42.0, LLVM 3.7.1) GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:635: Max Alloc: 268435456 bytes GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:636: Local Mem: 32768 bytes GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:639: Iteration size: (2048, 4096) GEGL-gegl-cl-init.c-Message: [GEGL_DEBUG_OPENCL] gegl-cl-init.c:746: Image Support Error GEGL-geglmodule.c-Message: Module '/usr/lib64/gegl-0.3/raw-load.so' load error: dlopen: cannot load any more object with static TLS (gegl-0.3:2146): GLib-GObject-WARNING **: Fatal error - Could not reload previously loaded plugin '(unknown)'
gcc -dumpversion: 5.3.0
Since TLS requires support from linker, dynamic linker and system libs, their installed versions might be of interest: sys-libs/glibc-2.21-r2 sys-devel/binutils-2.25.1-r1 I compiled the whole system with gcc-5.3.0 and flags, listed above. Only exemptions are a few packages non-system packages that had to be compiled with gcc-4* ( have gcc-4.9.3 for that) and a few non-system packages and libs that were compiled with LTO. ( Like Codeblocks, Codelite, a few media players etc).
(In reply to Branko Badrljica from comment #4) > I compiled {babl,gegl} with several FLAG versions, LTO and non-LTO, always > with same result. I tried also using gcc-4.9.3 - with the same result. If you don't rely on raw support you could try USE=-raw for a workaround with Gegl. Other than that I would play with flags -mtls-dialect=traditional -mtls-dialect=gnu -mtls-size=22 -mtls-size=64 -mtls -ftls-model=local-dynamic -ftls-model=local-exec personally, if you haven't tried all, yet.
I've made fuckup with binutils it seems, but so far it doesn't show to be related to this. I needed newer binutils and installed 2.25.1-r1 and those screw with quite a few packages. But I downgraded them to 2.25 and rebuilt whole @systemd + ( a few failing packages) + gegl dependencies with it. With same result - no-go for gegl. Playing with tls flags gave no useful result. But this is interesting: If i make local repo gegl-gt by hand and compile it by hand, then it works. I've copied from portage logfile exact ./configure statement used, and CFLAGS|LDFLAGS from emerge --info. Stuff, compiled by hand seems to be working- BUT NOT when I set prefix to /usr. I have to make install to lo local dir and then copy resulting programs and libraries by hand to final /usr/{bin|lib} destination. And use patchelf --set-rpath on binaries to edit the search path. And set GEGL_PATH so that gegl binary knows where to look for modules. Weird.
Update: I tried tracing the testcase through linker ( started gegl through LD_DEBUG=all /lib64/ld-2.21.so /usr/bin/gegl-0.3 .... ). I have noticed strange errors, like: /usr/lib64/babl-0.1/naive-CMYK.so: error: symbol lookup error: undefined symbol: destroy (fatal) These appear whenever some babl module gets loaded. And: /usr/lib64/gegl-0.3/edge-sobel.so: error: symbol lookup error: undefined symbol: g_module_check_init (fatal) These appear, whenever gegl loads gegl module. But at least when gegl and its libraries are used out of /usr/lib, whole thing appears to work- I get cirresponging png on the output and it appears to be good. But when I use GEGL_PATH=/usr/lib, linker gets into shitstorm of dependecy linking, resolving, reloacting etc and whole thing crashes with: GEGL-geglmodule.c-Message: Module '/usr/lib64/gegl-0.3/raw-load.so' load error: dlopen: cannot load any more object with static TLS
gimp-2.8.14 and gegl-0.2.0-r2 work fine, though.
I have found a couse somewhere within the fact that libraw doesn't like to be compiled with gcc-5.3.0 and it doesn't like to be linked with its system libs. gcc-config doesn't help since it maintains all gcc libraries within /etc/ld.so.conf.d/05gcc-x86_64-pc-linux-gnu.conf, with 5.30 libraries listed before all others. Just rearanging the list so that gcc-4.9.3 libs were listed ahead made my testcase work - after ldconfig Unfortunately, I can't use this solution globaly, so for now I just simply switched off "raw" option for gegl...
