Opened 12 years ago

Closed 12 years ago

Last modified 9 years ago

#1066 closed bug (wontfix)

MacOSX powerpc gcc 3.3/4.0 and unknown symbol `_printf$LDBLStub'

Reported by: gracjan-agh.edu.pl Owned by: thorkilnaur
Priority: normal Milestone: 6.6.1
Component: Compiler Version: 6.6
Keywords: Cc:
Operating System: MacOS X Architecture: powerpc
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

There are problems with linking on MacOSX 10.4.8 when selected gcc 3.3. Following session demonstrates problem:

gracjan$ sudo gcc_select 3.3
Default compiler has been set to:
gcc version 3.3 20030304 (Apple Computer, Inc. build 1819)
gracjan$ ghc --make x.hs
[1 of 1] Compiling Main             ( x.hs, x.o )
Linking x ...
ld: Undefined symbols:
_sprintf$LDBLStub
_fprintf$LDBLStub
_vfprintf$LDBLStub
gracjan$ sudo gcc_select 4.0
Default compiler has been set to:
gcc version 4.0.1 (Apple Computer, Inc. build 5363)
gracjan$ ghc --make x.hs
Linking x ...
gracjan$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.6

Linking manually with -lSystemStubs fixes the problem. Seems to be connected with Ticket #1018, where the solution is to only add -lSystemStubs when build evironment says so. Probably adding it always could be a solution.

Affected: ghc-6.6-ppc-apple-darwin.tar.gz from http://haskell.org/ghc/download_ghc_66.html, also macports:

gracjan$ port info ghc
ghc 6.6, Revision 2, lang/ghc (Variants: darwin_6, darwin_7_powerpc, darwin_8_powerpc, darwin_8_i386, noopengl)
http://www.haskell.org/ghc
Library Dependencies: readline, gmp
Runtime Dependencies: perl5.8
Platforms: darwin

Change History (6)

comment:1 Changed 12 years ago by wolfgang

difficulty: UnknownEasy (1 hr)
severity: normalminor

Is there any reason to still use ghc 3.3?


This is a problem with the underlying GCC, which always fails when trying to link a gcc4-compiled .o file that references printf:

gould:~/Experiments wolfgang$ gcc-4.0 -arch ppc -c hello.c
gould:~/Experiments wolfgang$ gcc-3.3 -arch ppc hello.o
ld: Undefined symbols:
_printf$LDBLStub

Fixing this involves

  • checking for -lSystemStubs availability during configure
  • adding it to the libs required by the RTS, if available
  • maybe doing the above olnly on powerpc-apple-darwin, as the lib is empty & useless on i386.

I'd hate to have to touch a configure script to fix a bug that is so easy to work around... any other volunteers?

comment:2 Changed 12 years ago by thorkilnaur

Owner: set to thorkilnaur

I'll look at this.

comment:3 Changed 12 years ago by igloo

Milestone: 6.6.1

comment:4 Changed 12 years ago by thorkilnaur

The basic problem as far as I am able to understand is that GHC has been built on a system using gcc-4.0 and is now being used on a system with gcc-3.3. Being built using gcc-4.0 means that some of the libraries, in particular libHSrts.a, contain references to these $LDBLStub-suffixed standard C library entry points. For example:

Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ nm /Users/thorkilnaur/tn/install/ghc-HEAD-for-1066-20070211_1657/lib/ghc-6.7.20070209/libHSrts.a
...
/Users/thorkilnaur/tn/install/ghc-HEAD-for-1066-20070211_1657/lib/ghc-6.7.20070209/libHSrts.a(StackOverflow.o):
  00000000 T _StackOverflowHook
         U ___sF
         U _fprintf$LDBLStub
         U dyld_stub_binding_helper
...
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$

So when linking with gcc-3.3, errors result:

Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ cat t2.hs
module Main where
  main = putStr ("t2: Hello trac 1066 2007-Feb-17 19.48\n")
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.7.20070209
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5250)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ ghc -fforce-recomp -pgml gcc-3.3 --make t2.hs
[1 of 1] Compiling Main             ( t2.hs, t2.o )
Linking t2 ...
ld: Undefined symbols:
_sprintf$LDBLStub
_fprintf$LDBLStub
_vfprintf$LDBLStub
_sscanf$LDBLStub
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ 

Whereas if we stay with gcc-4.0, all is well:

Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ ghc -fforce-recomp --make t2.hs
[1 of 1] Compiling Main             ( t2.hs, t2.o )
Linking t2 ...
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ 

So far, I have just repeated what the original reporter of this problem has done.

When getting to the easy work-around, however, I must admit that it took me a while to find it. Simply adding -lSystemStubs to the ghc command is not sufficient:

Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ ghc -fforce-recomp -pgml gcc-3.3 --make t2.hs -lSystemStubs
[1 of 1] Compiling Main             ( t2.hs, t2.o )
Linking t2 ...
ld: Undefined symbols:
_sprintf$LDBLStub
_fprintf$LDBLStub
_vfprintf$LDBLStub
_sscanf$LDBLStub
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ 

One possibility is to use the ghc -v option to get a listing of the link command and then add -lSystemStubs to the end of that. Another possibility is to "guess" that HSrts is the library that needs these symbols and add -lHSrts before the -lSystemStubs:

Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ ghc -fforce-recomp -pgml gcc-3.3 --make t2.hs -lHSrts -lSystemStubs
[1 of 1] Compiling Main             ( t2.hs, t2.o )
Linking t2 ...
Thorkil-Naurs-Computer:~/tn/GHC/trac/1066/base thorkilnaur$ 

And that actually works.

So what to do about this? I must admit, Wolfgang, that I don't really see how the fix that you propose would work: It seems to be a change in the GHC build process, but the difference between gcc versions is apparent only in the GHC user's environment. And this could be entirely different if the user had installed a binary GHC.

Specifically, you seem to propose something that will wire this SystemStubs library into the GHC installation. If that is correctly understood and SystemStubs, as I interpret it, provides a bridge from gcc-4.0 compiled code to gcc-3.3 libraries, how would the resulting GHC work in an environment entirely without gcc 3.3?

However, I could very well be off the track here and welcome additional comments.

What I propose to do presently is to write a GHC FAQ entry about the matter and then close this ticket with resolution wontfix. After all, the work-around does not seem particularly more difficult than the technique described in the User's Guide section "Options affecting linking" http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-linker to ensure that the HSrts library main() function is used, rather than some other main() function defined in the code.

And, again, additional comments on this matter would be most welcome.

comment:5 Changed 12 years ago by thorkilnaur

Resolution: wontfix
Status: newclosed

So here is the FAQ entry:

http://haskell.org/haskellwiki/GHC/FAQ#Linking_with_ghc_produces_ld:_Undefined_symbols:__sprintf.24LDBLStub_...

And I will close this ticket. Please don't hesitate to re-open if this does not settle the matter for you.

comment:6 Changed 9 years ago by simonmar

difficulty: Easy (1 hr)Easy (less than 1 hour)
Note: See TracTickets for help on using tickets.