[Buildroot] [Bug 7322] New: libgomp dependency issue with imagemagick

[Buildroot] [Bug 7322] New: libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

           Summary: libgomp dependency issue with imagemagick
           Product: buildroot
           Version: 2014.05
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P5
         Component: Other
        AssignedTo: unassigned at buildroot.uclibc.org
        ReportedBy: benoit.thebaudeau.dev at gmail.com
                CC: buildroot at uclibc.org
   Estimated Hours: 0.0


With the current master head, if an external toolchain with libgomp support is
used to build imagemagick, libgomp is installed to staging/, but not to target/
by default, so imagemagick's configure detects libgomp as supported and enables
its usage for the build stage, but then it fails to run on the target because
libgomp is missing.

This can be worked around by manually adding libgomp.so* to the list of
toolchain libraries to be installed to the target, but this should be an
automatic dependency. However, AFAIK, there is currently no dependency
mechanism in BuildRoot to trigger the installation of a toolchain library to
the target.

A solution could be to create an automatic or manual
BR2_TOOLCHAIN_SUPPORTS_LIBGOMP config option, and a hidden
BR2_PACKAGE_IMAGEMAGICK_USES_LIBGOMP defaulting to
BR2_TOOLCHAIN_SUPPORTS_LIBGOMP and selecting a
BR2_TOOLCHAIN_INSTALL_TARGET_LIBGOMP, which would trigger the installation of
libgomp.so* from one of the toolchain make files.

What do you think?

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Buildroot] [Bug 7322] libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

--- Comment #1 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 2014-08-15 10:35:54 UTC ---
Thanks for your clear bug report.
How 'standard' is libgomp in external toolchains? Is it something that is
present in a typical toolchain, or does it have to be enabled explicitly?

How large is this library (stripped)?

We could simply copy libgomp* to the target when present, regardless of any
package dependency like imagemagick.
In toolchain/toolchain-external/toolchain-external.mk, we would have to extend
the LIB_EXTERNAL_LIBS variable with libgomp.

If either the presence of libgomp is not standard, or it is sufficiently small,
then this would be a fine strategy I believe...

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Buildroot] [Bug 7322] libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

--- Comment #2 from Gustavo Zacarias <gustavo@zacarias.com.ar> 2014-08-15 10:51:19 UTC ---
There's already a config symbol for OpenMP (libgomp) support which could easily
be extended.
A quick fix for 2014.08 would be to --disable-openmp for imagemagick if
BR2_GCC_ENABLE_OPENMP isn't set (it's just used/supported for the internal
toolchain backend so nothing to worry about there, otherwise the test is
automatic).

Going forward i'd just copy it if it's available, it's not that big, an ARMv5
libgomp.so is roughly 100 KiB without stripping.
We could introduce a config knob like BR2_TOOLCHAIN_EXTERNAL_INET_RPC and those
but really, it's just complicating things i think.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Buildroot] [Bug 7322] libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

--- Comment #3 from Beno?t Th?baudeau <benoit.thebaudeau.dev@gmail.com> 2014-08-15 13:04:47 UTC ---
Yes, libgomp is not very big. It seems to be now present in most toolchains,
but it is optional.

I also think that doing something for imagemagick here is the wrong way to go,
not only because it complicates things, but also because other packages may
silently (unless they're run on the target) be affected by the same issue,
either for libgomp or for another toolchain library.

I agree that something like BR2_TOOLCHAIN_EXTERNAL_INET_RPC would be overkill,
because this is rather used for feature / package filtering than for library
installation.

Looking at copy_toolchain_lib_root, adding libgomp.so* to LIB_EXTERNAL_LIBS
should work even if this library is not available, so this is indeed a good
solution. And this will make it possible to easily add other optional standard
(i.e. non-exotic) libraries in the same way in the future if a similar issue
happens elsewhere.

I will probably send a patch next week if nobody beats me at it.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Buildroot] [Bug 7322] libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

--- Comment #4 from Samuel Martin <s.martin49@gmail.com> 2014-08-15 13:52:21 UTC ---
I agree about disabling OpenMP support for imagemagick for the release.

However, for the long-term solution, I would perfer having a knob and a check
for external toolchain.

Having a knob allows to avoid relying on the package's build-system black
magics, so one excatly knows how a package is configure/built, so what is put
in its image.
E.g. OpenCV can takes benefit from OpenMP but it is disabled
(http://git.buildroot.net/buildroot/commit/package/opencv/opencv.mk?id=2abfd50aefdc89cf1b858c6c965a5e7d94a413b4),
mostly because of the magics that is done at configure time:
- if you don't ask for OpenMP support (default) or force ot be off, then it is
disabled;
- if you ask for OpenMP support:
  - if OpenMP is found, then it is enabled;
  - if OpenMP is not found, then it is disabled.

So, in the OpenCV case, if we don't have a knob, we should always ask for
OpenMP support on the configure cmdline to get it only if available.

This is completely missleading for the buildroot user, that will see
"-DWITH_OPENMP=ON" in the package/opencv.mk file, but he/she won't get OpenMP
support without any warning (unless he/she carefully read the build logs) if
its toolchain does not have it.

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Buildroot] [Bug 7322] libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

--- Comment #5 from Beno?t Th?baudeau <benoit.thebaudeau.dev@gmail.com> 2014-08-20 17:07:25 UTC ---
See:
http://lists.busybox.net/pipermail/buildroot/2014-August/104725.html
http://patchwork.ozlabs.org/patch/381736/

Thomas, Gustavo, have you changed your mind following Samuel's comment?

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Buildroot] [Bug 7322] libgomp dependency issue with imagemagick

[bugzilla at busybox.net]

https://bugs.busybox.net/show_bug.cgi?id=7322

Thomas De Schampheleire <patrickdepinguin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Thomas De Schampheleire <patrickdepinguin@gmail.com> 2014-08-21 20:21:27 UTC ---
Workaround committed:
http://git.buildroot.org/buildroot/commit/?id=9579e6aac33aa828aa5a447727440be7b85efb03

Longer term solutions will be submitted through the mailing list, so marking
this as fixed.

Thanks for reporting!

-- 
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.