Comment 1 Koop Mast 2014-06-19 20:28:46 UTC

Grab looks like a IM issue.

configure:10409: checking for librsvg-2.0 >= 2.11.0
configure:10423: result: yes CFLAGS='-I/usr/local/include/librsvg-2.0 -I/usr/local/include/gdk-pixbuf-2.0 -pthread -I/usr/local/include/cairo -I/usr/local/include/glib-2.0 -I/usr/local/include/pixman-1  -I/usr/local/include/freetype2 -I/usr/local/include/libpng15 -D_THREAD_SAFE -I/usr/local/include  ' LIBS='-lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -L/usr/local/lib -lcairo -pthread  '
configure:10480: checking for Wand >= 6.2.8
configure:10494: result: yes CFLAGS='-I/usr/local/include/ImageMagick-6 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16  ' LIBS='-lMagickWand-6.Q16 -L/usr/local/lib -lMagickCore-6.Q16  '
configure:10535: checking for MagickExportImagePixels
configure:10535: cc -o conftest -I/usr/local/include -O2 -pipe -fno-strict-aliasing -I/usr/local/include/librsvg-2.0 -I/usr/local/include/gdk-pixbuf-2.0 -pthread -I/usr/local/include/cairo -I/usr/local/include/glib-2.0 -I/usr/local/include/pixman-1  -I/usr/local/include/freetype2 -I/usr/local/include/libpng15 -D_THREAD_SAFE -I/usr/local/include   -I/usr/local/include/ImageMagick-6 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16   -I/usr/local/include   -I/usr/local/include  -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib -Wl,-znocombreloc -L/usr/local/lib conftest.c -lMagickWand-6.Q16 -L/usr/local/lib -lMagickCore-6.Q16   -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -L/usr/local/lib -lcairo -pthread   -lX11 -lpthread -lutil  >&5 
/usr/local/lib/libMagickCore-6.Q16.so: undefined reference to `omp_destroy_lock@OMP_3.0'
/usr/local/lib/libMagickCore-6.Q16.so: undefined reference to `omp_set_lock@OMP_3.0'
/usr/local/lib/libMagickCore-6.Q16.so: undefined reference to `omp_init_lock@OMP_3.0'
/usr/local/lib/libMagickCore-6.Q16.so: undefined reference to `omp_unset_lock@OMP_3.0'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
configure:10535: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "emacs"

Comment 2 Koop Mast 2014-06-19 20:29:54 UTC

Kevin now that I look again that the output did you enable the OPENMP option?

No openMP.
     OPENMP=off: Parallel processing support via OpenMP
Butperhaps emacs want it.

Tried today with ImageMagick built with OPENMP enabled, but got the same error.

I have tracked this down and it is not directly tied to the OPENMP option.

These symbols should be provided by libgomp, the GNU OpenMP library. But it's not a part of OpenMP, it is a part of gcc. 

I see that there are two libgomp.so.1 libs on the system. One is in the base system (/usr/lib) and the other is from lang/gcc (/usr/local/lib). While the one installed by the port has the required symbols, the base library does not have any symbols (at least as reportd by (objdump). I guess it is a stub. Looks like IamgeMagick links to the "real" library, but emacs finds the stub when configuring, so it dies.

I'll continue to play with this, but the solution might be obvious to someone familiar with this sort of issue.

I have confirmed the problem by moving the stub library (and symlink) in /usr/lib out of the way. emacs builds cleanly at this point.

From config.log:
configure:10699: cc -o conftest -I/usr/local/include -O2 -pipe -fno-strict-aliasing -I/usr/local/include/librsvg-2.0 -I/usr/local/include/gdk-pixbuf-2.0 -pthread -I/usr/local/include/cairo -I/usr/local/include/glib-2.0 -I/usr/local/include/pixman-1  -I/usr/local/include/freetype2 -I/usr/local/include/libpng15 -D_THREAD_SAFE -I/usr/local/include   -I/usr/local/include/ImageMagick-6 -fopenmp -DMAGICKCORE_HDRI_ENABLE=0 -DMAGICKCORE_QUANTUM_DEPTH=16   -I/usr/local/include/gtk-2.0 -I/usr/local/include/gio-unix-2.0/ -I/usr/local/include/atk-1.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -D_THREAD_SAFE -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/pango-1.0 -pthread  -I/usr/local/include/freetype2 -I/usr/local/include/libpng15 -I/usr/local/include/harfbuzz -I/usr/local/include/glib-2.0 -I/usr/local/include   -I/usr/local/include   -I/usr/local/include  -L/usr/local/lib -Wl,-rpath=/usr/lib:/usr/local/lib -Wl,-znocombreloc -L/usr/local/lib conftest.c -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage -lXfixes -lX11 -latk-1.0 -lcairo -pthread -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lfontconfig -lfreetype -L/usr/local/lib -lglib-2.0 -lintl   -lMagickWand-6.Q16 -L/usr/local/lib -lMagickCore-6.Q16   -lrsvg-2 -lm -lgio-2.0 -lgdk_pixbuf-2.0 -lgobject-2.0 -lglib-2.0 -lintl -L/usr/local/lib -lcairo -pthread   -lX11 -lpthread -lutil  >&5 

Note the -rpath=/usr/lib:/usr/local/lib which results in the stub being used instead of the real library.

Now that I have my editor back, I'll try to generate a patch to fix this and submit it.

Comment 7 Koop Mast 2014-06-27 16:38:10 UTC

So it seems this is a emacs issue which is mostly likely exposed by the recent IM update. But I haven't had any luck trying to reproduce this.

I'll admit that I am rather confused about what is going on with this.

Why are the ImageMagick libs linking to libgomp when the OPENMP option is not selected? When I look at libMagickCore on a FreeBSD-9.2 system, it is not linked to libgomp. On by 10-Stable system I am seeing:
	libgomp.so.1 => /usr/local/lib/gcc47/libgomp.so.1 (0x2fb09000)
	libgcc_s.so.1 => /usr/local/lib/gcc47/libgcc_s.so.1 (0x2fd17000)
[..]
	libc++.so.1 => /usr/lib/libc++.so.1 (0x32b1a000)
	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x32dda000)
All of those are missing when IM is built on 9.2. (Of course, libstdc++.so.6 replaces the latter two).

I am unclear on why the linking of emacs with the two IM libraries generates those errors when the stub library is present in /usr/lib. If I move it aside without rebuilding IM, emacs builds correctly. (Thank goodness! Using vi is pretty painful for me.)

I do suspect that the rpath used both in configure and the actual build that lists /usr/lib before /usr/local/lib is involved, but I'lladmit to never having looked at the details of how rpath and ld do things. I asked about it on ports@, but have received no replies.

I am also unclear on the function of the stub library. I shows no symbols but all four of the "missing" symbols are listed as dynamic symbols.

Comment 9 Ashish SHUKLA 2014-06-28 17:52:25 UTC

(In reply to rkoberman from comment #8)
> I'll admit that I am rather confused about what is going on with this.
> 
> Why are the ImageMagick libs linking to libgomp when the OPENMP option is
> not selected? When I look at libMagickCore on a FreeBSD-9.2 system, it is
> not linked to libgomp. On by 10-Stable system I am seeing:
> 	libgomp.so.1 => /usr/local/lib/gcc47/libgomp.so.1 (0x2fb09000)
> 	libgcc_s.so.1 => /usr/local/lib/gcc47/libgcc_s.so.1 (0x2fd17000)
> [..]
> 	libc++.so.1 => /usr/lib/libc++.so.1 (0x32b1a000)
> 	libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x32dda000)
> All of those are missing when IM is built on 9.2. (Of course, libstdc++.so.6
> replaces the latter two).
> 
> I am unclear on why the linking of emacs with the two IM libraries generates
> those errors when the stub library is present in /usr/lib. If I move it
> aside without rebuilding IM, emacs builds correctly. (Thank goodness! Using
> vi is pretty painful for me.)
> 
> I do suspect that the rpath used both in configure and the actual build that
> lists /usr/lib before /usr/local/lib is involved, but I'lladmit to never
> having looked at the details of how rpath and ld do things. I asked about it
> on ports@, but have received no replies.
> 
> I am also unclear on the function of the stub library. I shows no symbols
> but all four of the "missing" symbols are listed as dynamic symbols.

I'm able to reproduce this with ImageMagick built with OPENMP option. Your ImageMagick (the one which uploaded log is for) is built with OPENMP support (as clear from the $(pkg-config --cflags Wand) present in the command-line), which depends on GCC 4.7, and as clear from the rpath of of "/usr/local/lib/libMagickCore-6.Q16.so".

RPATH is only used for runtime linking. I think a fix here would be to build emacs with same compiler as ImageMagick, because of OpenMP, and ofcourse it passes the ImageMagick test with CC=gcc47 CPP=cpp47 CXX=g++47.

After updating IM to the latest version, I no longer see it pulling in libgomp.so when OPENMP is not selected. As a result, emacs now configures and builds correctly.

If I do build IM with OPENMP, I still get the same failure as before unless I move /usr/lib/libMagickCore.6.Q16.so.1 aside, so things are still a bit off.

I am baffled as to why IM was building with OpenMP even though I did not have the option selected. I even did a "make showconfig" and included the output of the line for OPENMP in this ticket.

In any case, as long as IM is not built with OPENMP selected, emacs builds, but fails if it is unless I move /usr/lib/libgomp aside.

Comment 11 Koop Mast 2014-06-28 19:24:59 UTC

(In reply to rkoberman from comment #10)
> I am baffled as to why IM was building with OpenMP even though I did not
> have the option selected. I even did a "make showconfig" and included the
> output of the line for OPENMP in this ticket.

This is because in the 6.8.9-3 update I added USES=compiler:openmp which pulls in lang/gcc because clang doesn't have openmp support (Looks like that clang 3.5 will have it though).

Before this it probably didn't enable openmp support, because the default compiler didn't support it. I should note that I never check exactly what happend in this case.

Comment 12 Koop Mast 2014-06-28 21:57:50 UTC

(In reply to Koop Mast from comment #11)
> (In reply to rkoberman from comment #10)
> > I am baffled as to why IM was building with OpenMP even though I did not
> > have the option selected. I even did a "make showconfig" and included the
> > output of the line for OPENMP in this ticket.
> 
> This is because in the 6.8.9-3 update I added USES=compiler:openmp which
> pulls in lang/gcc because clang doesn't have openmp support (Looks like that
> clang 3.5 will have it though).
> 
> Before this it probably didn't enable openmp support, because the default
> compiler didn't support it. I should note that I never check exactly what
> happend in this case.

And I read the question wrong.

The reason why the link issue happens is because the compiler:openmp.

About IM linking openmp without the option, I have no idea. I didn't touch the openmp logic at all.

Comment 13 Ashish SHUKLA 2014-09-29 04:04:24 UTC

Hi,

Just tried latest update of graphics/ImageMagick with OPENMP and it does not seem to happen now. Could you please check ?

Thanks,
Ashish