__emutls_get_address link problem

Christian Maeder

23 Aug 2010 23 Aug '10

11:57 a.m.

Hi, I've created a sparc solaris installation of ghc-6.12.3 using gcc-4.3.3 However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts! With ghc-6.12.1 and gcc-4.x.y (x < 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. Does anybody have an explanation or proposal to fix this? Thanks Christian Linking Hello ... /home/pub-bkb/ghc/ghc-6.12.3/lib/ghc-6.12.3/libHSrts_thr.a(GC.thr_o): In function `scavenge_until_all_done': GC.c:(.text+0x178): undefined reference to `__emutls_get_address' GC.c:(.text+0x204): undefined reference to `__emutls_get_address' GC.c:(.text+0x250): undefined reference to `__emutls_get_address' GC.c:(.text+0x27c): undefined reference to `__emutls_get_address' GC.c:(.text+0x338): undefined reference to `__emutls_get_address' /home/pub-bkb/ghc/ghc-6.12.3/lib/ghc-6.12.3/libHSrts_thr.a(GC.thr_o):GC.c:(.text+0x408): more undefined references to `__emutls_get_address' follow collect2: ld returned 1 exit status -bash-3.00$ gcc -v Reading specs from /export/local/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/specs Configured with: ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77: (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 Thread model: posix gcc version 3.4.4 gcc used for Building ghc-6.12.3 Using built-in specs. Target: sparc-sun-solaris2.8 Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 --exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-stage1-languages=c --enable-languages=ada,c,c++,fortran,java,objc Thread model: posix gcc version 4.3.3 (GCC)

Show replies by date

Brandon S Allbery KF8NH

23 Aug 23 Aug

12:45 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/23/10 11:57 , Christian Maeder wrote:

...

However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x < 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4.

You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxypcMACgkQIn7hlCsL25XfwQCgobnqHhGUL+uvKQ1o++yL6kt7 m3MAn2BV55Tvv2gfG8WEV3jyATeAVytN =LGuK -----END PGP SIGNATURE-----

Simon Marlow

25 Aug 25 Aug

4:32 a.m.

On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4.

You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4.

In particular, thread-local variables, which are used by the parallel GC. Cheers, Simon

Christian Maeder

8:15 a.m.

Simon Marlow schrieb:

...

On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4.

You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4.

In particular, thread-local variables, which are used by the parallel GC.

I'm just testing if I get runtime problems, but the linking error goes away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir. C.

Christian Maeder

11:37 a.m.

Christian Maeder schrieb:

...

Simon Marlow schrieb:

...
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4.

Why should it not be possible to create object files (like also dynamic libs) with (very) different compilers?

...

...
In particular, thread-local variables, which are used by the parallel GC.

I'm just testing if I get runtime problems, but the linking error goes away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir.

The hack seems to work, although it looks dangerous regarding other symbols from libgcc_eh.a that should be in sync with the used gcc-3.4.4. C.

Simon Marlow

11:39 a.m.

On 25/08/2010 16:37, Christian Maeder wrote:

...

Christian Maeder schrieb:

...
Simon Marlow schrieb:

...
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4.

Why should it not be possible to create object files (like also dynamic libs) with (very) different compilers?

This is a case where the ABI changed between versions of gcc (I presume). It rarely happens with C code, but happens more often with C++, and, of course, in GHC we change the ABI with every single release so you should be used to this by now :-)

...

...
...
In particular, thread-local variables, which are used by the parallel GC.

I'm just testing if I get runtime problems, but the linking error goes away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir.

The hack seems to work, although it looks dangerous regarding other symbols from libgcc_eh.a that should be in sync with the used gcc-3.4.4.

I wouldn't trust it. Why do you need to mix code compiled by two different gcc versions? Cheers, Simon

scooter.phd＠gmail.com

6:05 p.m.

Christian: Is it possible that you might have code compiled with an older version of ghc lying around in an odd place in your build hierarchy? I would imagine that you upgraded cabal-installed packages. If for some reason you copied or used rsync to replicate a directory tree onto the older machine, then that would explain why you are seeing these difficulties. -scooter Sent from my Verizon Wireless BlackBerry -----Original Message----- From: Simon Marlow Sender: glasgow-haskell-users-bounces@haskell.org Date: Wed, 25 Aug 2010 16:39:43 To: Christian Maeder Cc: Subject: Re: __emutls_get_address link problem On 25/08/2010 16:37, Christian Maeder wrote:

...

Christian Maeder schrieb:

...
Simon Marlow schrieb:

...
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4.

Why should it not be possible to create object files (like also dynamic libs) with (very) different compilers?

...

...
...
In particular, thread-local variables, which are used by the parallel GC.

I'm just testing if I get runtime problems, but the linking error goes away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir.

The hack seems to work, although it looks dangerous regarding other symbols from libgcc_eh.a that should be in sync with the used gcc-3.4.4.

I wouldn't trust it. Why do you need to mix code compiled by two different gcc versions? Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Christian Maeder

26 Aug 26 Aug

5:08 a.m.

scooter.phd@gmail.com schrieb:

...

Christian:

Is it possible that you might have code compiled with an older version of ghc lying around in an odd place in your build hierarchy? I would imagine that you upgraded cabal-installed packages. If for some reason you copied or used rsync to replicate a directory tree onto the older machine, then that would explain why you are seeing these difficulties.

No, I had a plan link error, that I resolved by supplying a (gcc) library that contained the missing symbol. I was hoping, that it was a configure issue (during compilation of ghc or during installation of a binary ghc distribution), but it does not look like it. I will not sell my hack. I just wanted to avoid to install a newer gcc or build an extra binary distribution (for that old sparc). Thanks for any feedback Christian

...

-scooter Sent from my Verizon Wireless BlackBerry

-----Original Message----- From: Simon Marlow Sender: glasgow-haskell-users-bounces@haskell.org Date: Wed, 25 Aug 2010 16:39:43 To: Christian Maeder Cc: Subject: Re: __emutls_get_address link problem

On 25/08/2010 16:37, Christian Maeder wrote:

...
...
Simon Marlow schrieb:

...
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4. Why should it not be possible to create object files (like also dynamic

Christian Maeder schrieb: libs) with (very) different compilers?

This is a case where the ABI changed between versions of gcc (I presume). It rarely happens with C code, but happens more often with C++, and, of course, in GHC we change the ABI with every single release so you should be used to this by now :-)

...
...
...
In particular, thread-local variables, which are used by the parallel GC. I'm just testing if I get runtime problems, but the linking error goes away, if I put libgcc_eh.a from gcc-4.3.3 into ghc's libdir. The hack seems to work, although it looks dangerous regarding other symbols from libgcc_eh.a that should be in sync with the used gcc-3.4.4.

I wouldn't trust it. Why do you need to mix code compiled by two different gcc versions?

Cheers, Simon _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Brandon S Allbery KF8NH

25 Aug 25 Aug

2 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/25/10 11:37 , Christian Maeder wrote:

...

Christian Maeder schrieb:

...
Simon Marlow schrieb:

...
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:

...
On 8/23/10 11:57 , Christian Maeder wrote:

...
However, when I try to compile the simplest source with on older gcc-3.4.4 I get the link error below, but only for the threaded rts!

With ghc-6.12.1 and gcc-4.x.y (x< 3) I did not have such a problem when switching to a machine that only has gcc-3.4.4. You got lucky; mixing GCC major versions like that is not expected (much less guaranteed) to work in general. GCC evidently changed the way it implements some thread support routines between gcc3 and gcc4.

Why should it not be possible to create object files (like also dynamic libs) with (very) different compilers?

All bets are off when it comes to compiler support routines. Anyone who's tried to link code generated by gcc with code generated by SunPro/Forte C on Solaris knows this one from experience. Those of us old enough to remember early versions of gcc do too; it took a while for the support to become stable, then libg++/libstdc++ went through the same thing later, then the gcc/egcs split (aka the gcc2/gcc3 split). Red Hat's cowboy 2.95.3 release also caused a lot of grief. gcc3 to gcc4 is the exception, not the rule. - -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx1WiYACgkQIn7hlCsL25Vb7wCgqa3cCKh3aTtd/OhyYQjkrwmD 5twAoLUPM0yXBjw7i701V6XTUxmA8D7D =/Nnw -----END PGP SIGNATURE-----

5381

Age (days ago)

5384

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Brandon S Allbery KF8NH
Christian Maeder
scooter.phd＠gmail.com
Simon Marlow