Bug 191193 - editors/emacs fails to build (May be graphics/ImageMagick issue)
Summary: editors/emacs fails to build (May be graphics/ImageMagick issue)
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Koop Mast
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-19 19:38 UTC by rkoberman
Modified: 2016-01-17 15:10 UTC (History)
3 users (show)

See Also:


Attachments
emacs config.log showing the details of the error (171.61 KB, text/plain)
2014-06-19 19:38 UTC, rkoberman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description rkoberman 2014-06-19 19:38:55 UTC
Created attachment 143934 [details]
emacs config.log showing the details of the error

emacs fails to build. the error indicates an missing symbols in the ImageMagick core library (libMagickCore-6.Q16.so). I re-built ImageMagick shortly prior to attempting to rebuild emacs. I am unsure if the problem is emacs or ImageMagick, but ImageMagick does pass all tests.

config.log attached.

System is:
FreeBSD rogue 10.0-STABLE FreeBSD 10.0-STABLE #1 r267116M: Thu Jun  5 09:00:40 PDT 2014     root@rogue.local:/usr/obj/usr/src/sys/VT  amd64
Comment 1 Koop Mast freebsd_committer 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 freebsd_committer 2014-06-19 20:29:54 UTC
Kevin now that I look again that the output did you enable the OPENMP option?
Comment 3 rkoberman 2014-06-19 23:42:44 UTC
No openMP.
     OPENMP=off: Parallel processing support via OpenMP
Butperhaps emacs want it.
Comment 4 rkoberman 2014-06-22 18:43:08 UTC
Tried today with ImageMagick built with OPENMP enabled, but got the same error.
Comment 5 rkoberman 2014-06-23 23:18:53 UTC
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.
Comment 6 rkoberman 2014-06-24 15:52:13 UTC
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 freebsd_committer 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.
Comment 8 rkoberman 2014-06-28 01:48:13 UTC
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 freebsd_committer 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.
Comment 10 rkoberman 2014-06-28 19:14:00 UTC
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 freebsd_committer 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 freebsd_committer 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 freebsd_committer 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