Please apply libgomp patch to GCC for Hardy Heron

Bug #235070 reported by James Phillips on 2008-05-26
30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gcc-4.2 (Ubuntu)
Undecided
Unassigned
Hardy
Undecided
pavel

Bug Description

In Ubuntu 8.04, the gcc 4.2.3 version of libgomp will not work with shared libraries, for example:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28482

explains the problem and has a simple gcc patch, apply and rebuild corrects the problem:

http://gcc.gnu.org/bugzilla/attachment.cgi?id=14788&action=view

This is corrected in GCC 4.3.0 according to the above link, but GCC 4.3.0 is not in Hardy Heron.

     James Phillips

I can confirm that this bug exists; using f2py with a Fortran code linked with libgomp exposes the bug.

I fixed by adding the attached dpatch file to the source .dep (apt-get source gcc-4.2) patch directory, including the file in rules.patch, and building a new set of packages from source. I am not sure if this works universally, but the dpatch is based on the gcc patch posted above by James, so it should work in general. This patch is supposed to be applied for gcc 4.3.0, but this at least fixes the bug for gcc 4.2.3.

Josh Finkbeiner

guidol (monk-e) on 2008-08-09
Changed in gcc-4.2:
status: New → Confirmed
Matthias Klose (doko) on 2008-09-05
Changed in gcc-4.2:
status: Confirmed → In Progress
status: New → In Progress
Martin Pitt (pitti) wrote :

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gcc-4.2:
status: In Progress → Fix Committed
James Phillips (zunzun) wrote :

Excellent! I should be able to test over the weekend.

     James

James Phillips (zunzun) wrote :

Same error during testing:

ImportError: /usr/lib/libgomp.so.1: cannot allocate memory in static TLS block

To verify that I have the correct libgomp from hardy-proposed, please check this timestamp:

ls -ltr /usr/lib/libgomp.so.1.0.0
-rw-r--r-- 1 root root 24084 2008-09-10 14:08 /usr/lib/libgomp.so.1.0.0

     James

Jake (jake-michaelson) wrote :

I've also got the error:

/usr/lib/libgomp.so.1: cannot allocate memory in static TLS block

with proposed hardy updates enabled:

ls -ltr /usr/lib/libgomp.so.1.0.0
-rw-r--r-- 1 root root 30024 2008-09-10 21:30 /usr/lib/libgomp.so.1.0.0

If I can provide any additional information I will. FYI, when compiled with icc the program works fine.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.2 - 4.2.4-3ubuntu3

---------------
gcc-4.2 (4.2.4-3ubuntu3) intrepid; urgency=low

  * Update to SVN 20081008 from the ubuntu/gcc-4_2-branch.
    - PR middle-end/37731 (wrong code), PR middle-end/36575 (wrong code),
      PR rtl-optimization/37544 (wrong code), PR target/37101 (wrong code),
      PR middle-end/35432 (ice-on-valid).
    - PR libgcj/8995 (race conditions in interpreter), PR libgcj/31890
      out-of-sync javaprims.h regenerated).
    - Fix naming of bridge targets in gjavah (wrong header generation).
  * Fix PR c/35437 (ice-on-invalid), taken from the gcc-4.3 branch.
    LP: #251744.
  * gij/gcj: Don't remove alternatives on upgrade. Addresses: #479950.
  * Fix PR libgomp/28432. LP: #235070.
  * debian/rules.conf: Filter empty '[]' and '!none' in control file (Andrea
    Gasparini). LP: #268132.

 -- Matthias Klose <email address hidden> Wed, 08 Oct 2008 13:48:28 +0200

Changed in gcc-4.2:
status: In Progress → Fix Released
Andrew Corrigan (acorriga) wrote :

I am using Ubuntu 8.04, amd64. I just encountered the exact same bug discussed above. I have an OpenMP code which I compile as a shared library with both ICC and GCC. I load these libraries using ctypes in Python.
When compiled with ICC it works fine, but with GCC I get the error message: OSError: /usr/lib/libgomp.so.1: cannot allocate memory in static TLS block

I have hardy-proposed enabled, yet the 4.2.4-3ubuntu3 package, which fixes this bug, does not seem to be available in the repository.

The only versions that I see are:
4.2.4-1ubuntu3 (hardy-updates)
4.2.3-2ubuntu7 (hardy)

I have 4.2.4-1ubuntu3. I see that 4.2.4-3ubuntu3 is available in 8.10, but upgrading to a non-LTS release is not possible.

Thanks,
Andrew

Brian Curtis (bcurtiswx) wrote :

Andrew,

You can request the update to be backported to hardy through a bug report. There are example reports at https://launchpad.net/hardy-backports/+filebug . I can take care of your backport request once you make the report if you send me a message with the bug number included.

Thank you for your help in making Ubuntu better

Keean (keean) wrote :

Hi,

This bug affects ImageMagic which is used in the ASP services we run. This has caused us to be unable to upgrade to Hardy.

Fixing this bug is critical.

What can we do to get a fixed package into Hardy as soon as possible?

Regards,
Keean.

beat (pub1-panter) wrote :

Keean

Compiling ImageMagick with --disable-openmp was a workaround for me (ImageMagick 6.4.7-8).

I agree with the above posters that a fixed package would really help...

Thanks

Keean (keean) wrote :

Okay, the request to back port the compiler has been rejected. I didn't realise there was a compile time fix for Image Magick.

What is being done to progress this bug? Should we open new bug reports to get fixed packages for each affected application?

Colin Watson (cjwatson) wrote :

The patch as applied was as follows:

--- libgomp/configure.tgt 2007/05/04 19:20:28 124444
+++ libgomp/configure.tgt 2007/05/04 19:21:18 124445
@@ -11,14 +11,11 @@
 # XLDFLAGS Add extra link flags to use.

 # Optimize TLS usage by avoiding the overhead of dynamic allocation.
-# This does require that the library be present during process
-# startup, so mark the library as not to be dlopened.
 if test $have_tls = yes ; then
   case "${target}" in

     *-*-linux*)
       XCFLAGS="${XCFLAGS} -ftls-model=initial-exec"
- XLDFLAGS="${XLDFLAGS} -Wl,-z,nodlopen"
       ;;
   esac
 fi

However, the upstream bug indicates that the XCFLAGS line needs to be removed too. Reopening.

Changed in gcc-4.2:
status: Fix Committed → Triaged
Matthias Klose (doko) wrote :

> However, the upstream bug indicates that the XCFLAGS line needs to be removed too.

well, not if you look at the trunk and the 4.3 branch. Unsure if the proposed solution is the correct one, or if something else is missing. However removing this optimization seems to be safe.

Keean (keean) wrote :

This is the error produced whn trying to compile PerlMagick.

Can't load '/root/.cpan/build/PerlMagick-6.40-0f_k64/blib/arch/auto/Image/Magick/Magick.so' for module Image::Magick: /usr/lib/libgomp.so.1: cannot allocate memory in static TLS block at /usr/lib/perl/5.8/DynaLoader.pm line 225.
 at t/blob.t line 20
Compilation failed in require at t/blob.t line 20.

Martin Pitt (pitti) wrote :

Matthias, what does the other change do?

+ * Update backport for PR28322 (Gunther Nikl). Emit warnings instead
+ of errors for unknown -Wno-* options.

Steve Langasek (vorlon) wrote :

Accepted into intrepid-proposed; please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Steve Langasek (vorlon) wrote :

I mean hardy-proposed, sorry.

Changed in gcc-4.2:
status: Triaged → Fix Committed
pavel (gchoty) on 2009-03-21
Changed in gcc-4.2:
assignee: nobody → gchoty
Martin Pitt (pitti) wrote :

Did anyone test this?

Steve Langasek (vorlon) wrote :

This has still not been published to hardy-updates despite being made available for testing 4 months ago. Is anyone able to confirm whether 4.2.4-1ubuntu4 fixes this problem? Is there a simple test case one can use to check this?

I'm not sure if a simple test case exists - this bugs seems to manifest in fairly unusual scenarios. We experienced this while creating "mex" modules for Matlab.

Using this trivial example (test.c):
#include <omp.h>
#include "mex.h"

void mexFunction( int nlhs, mxArray *plhs[],
                  int nrhs, const mxArray *prhs[] )
{

int nthreads, tid;
#pragma omp parallel private(nthreads, tid)
  {
  tid = omp_get_thread_num();
  printf("Hello World from thread = %d\n", tid);

  if (tid == 0)
    {
    nthreads = omp_get_num_threads();
    printf("Number of threads = %d\n", nthreads);
    }
  }
}

And compiling with:
gcc -fopenmp -fPIC -o test.mexa64 -shared -I/opt/matlab/extern/include test.c

We get the following error:
$ export OMP_NUM_THREADS=4; echo "test" | matlab -nodisplay
>> ??? Invalid MEX-file
'/home/user/testmex/test.mexa64':
/usr/lib/libgomp.so.1: cannot allocate memory in static TLS block.

This is with gcc-4.2-base and libgomp1 4.2.4-1ubuntu3

After upgrading to gcc-4.2-base and libgomp1 4.2.4-1ubuntu4, the code works properly:

$ export OMP_NUM_THREADS=4; echo "test" | matlab -nodisplay
>> Hello World from thread = 1
Hello World from thread = 3
Hello World from thread = 2
Hello World from thread = 0
Number of threads = 4

So, at least for this specific case of a Matlab mex module dynamically linked to libgomp, 4.2.4-1ubuntu4 fixes the problem.

I hope this helps...

Steve Langasek (vorlon) wrote :

thanks, that's the confirmation we were looking for. Publishing to hardy-updates.

tags: added: verification-done
removed: verification-needed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gcc-4.2 - 4.2.4-1ubuntu4

---------------
gcc-4.2 (4.2.4-1ubuntu4) hardy-proposed; urgency=low

  * Fix PR libgomp/28432. LP: #235070, using the patch in intrepid.
  * Update backport for PR28322 (Gunther Nikl). Emit warnings instead
    of errors for unknown -Wno-* options.

 -- Matthias Klose <email address hidden> Mon, 19 Jan 2009 19:41:43 +0100

Changed in gcc-4.2 (Ubuntu Hardy):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related questions