Bug 7322

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...

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.

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.

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.

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?

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!