Opened 7 years ago

Closed 15 months ago

#1786 closed bug (worksforme)

can't build ghc-6.8.0.20071017 under Solaris using a GNU linker

Reported by: guest Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.8
Keywords: Cc: Christian.Maeder@…
Operating System: Solaris Architecture: x86
Type of failure: None/Unknown Difficulty: Moderate (less than a day)
Test Case: Blocked By:
Blocking: Related Tickets:

Description

if I have a GNU linker first in my PATH then configure allows the -x option for linking, but then the stage1/ghc-inplace still uses the Solaris linker via gcc and fails:

/usr/ccs/bin/ld: illegal option -- x
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s)
        [-64]           enforce a 64-bit link-edit
        [-a]            create an absolute file
        [-b]            do not do special PIC relocations in a.out
        [-B direct | nodirect]
                        establish direct bindings, or inhibit direct binding
                        to, the object being created
        [-B dynamic | static]
                        search for shared libraries|archives
        [-B eliminate]  eliminate unqualified global symbols from the
                        symbol table
        [-B group]      relocate object from within group
        [-B local]      reduce unqualified global symbols to local
        [-B reduce]     process symbol reductions
        [-B symbolic]   bind external references to definitions when creating
                        shared objects
        [-c name]       record configuration file `name'
        [-C]            demangle C++ symbol name diagnostics
        [-d y | n]      operate in dynamic|static mode
        [-D token,...]  print diagnostic messages
        [-e epsym]      use `epsym' as entry point address
        [-f name]       specify library for which this file is an auxiliary
                        filter
        [-F name]       specify library for which this file is a filter
        [-G]            create a shared object
        [-h name]       use `name' as internal shared object identifier
        [-i]            ignore LD_LIBRARY_PATH setting
        [-I name]       use `name' as path of interpreter
        [-l x]          search for libx.so or libx.a
        [-L path]       search for libraries in directory `path'
        [-m]            print memory map
        [-M mapfile]    use processing directives contained in `mapfile'
        [-N string]     create a dynamic dependency for `string'
        [-o outfile]    name the output file `outfile'
        [-p auditlib]   identify audit library to accompany this object
        [-P auditlib]   identify audit library for processing the dependencies
                        of this object
        [-Q y | n]      do|do not place version information in output file
        [-r]            create a relocatable object
        [-R path]       specify a library search path to be used at run time
        [-s]            strip any symbol and debugging information
        [-S supportlib]
                        specify a link-edit support library
        [-t]            do not warn of multiply-defined symbols that have
                        different sizes or alignments
        [-u symname]    create an undefined symbol `symname'
        [-V]            print version information
        [-Y P,dirlist]  use `dirlist' as a default path when searching for
                        libraries
        [-z absexec]    when building an executable absolute symbols
                        referenced in dynamic objects are promoted to
                        the executable
        [-z allextract | defaultextract | weakextract]
                        extract all member files, only members that resolve
                        undefined tor tentative symbols, or allow extraction of
                        archive members to resolvetweak references from
                        archive files
        [-z altexec64]  execute the 64-bit link-editor
        [-z combreloc]  combine multiple relocation sections
        [-z defs]       disallow undefined symbol references
        [-z direct | nodirect]
                        enable|disable direct binding to shared object
                        dependencies
        [-z endfiltee]  marks a filtee such that it will terminate a filters
                        search
        [-z finiarray=function]
                        name of function to be appended to the .finiarray
        [-z groupperm | nogroupperm]
                        enable|disable setting of group permissions
                        on dynamic dependencies
        [-z help ]      print this usage message
        [-z ignore | record]
                        ignore|record unused dynamic dependencies
        [-z initarray=function]
                        name of function to be appended to the .initarray
        [-z initfirst]  mark object to indicate that its .init section should
                        be executed before the .init section of any other
                        objects
        [-z interpose]  dynamic object is to be an `interposer' on direct
                        bindings
        [-z lazyload | nolazyload]
                        enable|disable delayed loading of shared object
                        dependencies
        [-z ld32=arg1,arg2,...]
                        define arguments applicable to the 32-bit class of ld(1)
        [-z ld64=arg1,arg2,...]
                        define arguments applicable to the 64-bit class of ld(1)
        [-z loadfltr]   mark filter as requiring immediate loading of its
                        filtees at runtime
        [-z muldefs]    allow multiply-defined symbols
        [-z nocompstrtab]
                        disable compression of string tables
        [-z nodefs]     allow undefined symbol references
        [-z nodefaultlib]
                        mark object to ignore any default library search path
        [-z nodelete]   mark object as non-deletable
        [-z nodlopen]   mark object as non-dlopen()'able
        [-z nodump]     mark object as non-dldump()'able
        [-z now]        mark object as requiring non-lazy binding
        [-z nopartial]  expand any partially initialized symbols
        [-z noversion]  don't record any version sections
        [-z origin]     mark object as requiring $ORIGIN processing
        [-z preinitarray=function]
                        name of function to be appended to the .preinitarray
        [-z redlocsym]  reduce local syms in .symtab to a minimum
        [-z rescan]     rescan archive list until no further member
                        extraction occurs
        [-z text]       disallow output relocations against text
        [-z textoff]    allow output relocations against text
        [-z textwarn]   warn if there are relocations against text
        [-z verbose]    generate warnings for suspicious processings
collect2: ld returned 1 exit status
<<ghc: 152856724 bytes, 17 GCs, 918602/1762740 avg/max bytes residency (2 samples), 19M in use, 0.00 INIT (0.00 elapsed), 0.82 MUT (6.75 elapsed), 0.08 GC (0.08 elapsed) :ghc>>
gmake[2]: *** [dist/build/GHC/Base.o] Error 1
-bash-3.1$ gcc -v
Using built-in specs.
Target: i386-pc-solaris2.10
Configured with: ../gcc-4.2.2/configure --prefix=/usr/local/lang -program-suffix=_4.2.2 --enable-64bit --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++
Thread model: posix
gcc version 4.2.2

This is bad since Cabal cannot cope with the solaris linker
(see http://hackage.haskell.org/trac/hackage/ticket/98)

Change History (17)

comment:1 Changed 7 years ago by igloo

  • Milestone set to 6.8.1

comment:2 Changed 7 years ago by duncan

This is a Cabal bug. See: http://hackage.haskell.org/trac/hackage/ticket/98

Distribution/Simple?/GHC.hs line 374:

  ldArgs = ["-r"]
        ++ ["-x"] -- FIXME: only some systems's ld support the "-x" flag
        ++ ["-o", ghciLibName <.> "tmp"]

We could fix this with a test during the configure step, or we could hack it and assume that if we're on Solaris then we never use -x. The latter is easy, the former is better.

Probably the right thing to do is in the configure step (in the Distribution.Simple.Configure.configure function) is after all the known programs have been configured, to run ld and test if it supports -x. If it does, use lookupProgram/updateProgram to update the ProgramConfiguration? with the configured ld program modified to have programArgs = -x?.

Any volunteers?

comment:3 follow-up: Changed 7 years ago by guest

I don't think it is a Cabal bug, because Cabal uses "ld" for linking which is a GNU linker that understands "-x". It's an error in ghc's configure approach. Linking should be (also) checked when using "gcc".

comment:4 in reply to: ↑ 3 Changed 7 years ago by duncan

Replying to guest:

I don't think it is a Cabal bug, because Cabal uses "ld" for linking which is a GNU linker that understands "-x".

I disagree. ld is the name of the standard system linker. On GNU systems that's GNU ld, on Solaris and OSX it's some other implementation.

comment:5 follow-up: Changed 7 years ago by guest

I've put a GNU linker first in my PATH! What other way has Cabal to find the "standard" linker?

-bash-3.1$ ld -V
GNU ld (GNU Binutils) 2.18
  Supported emulations:
   elf_i386_ldso
   elf_i386
   elf_x86_64

comment:6 in reply to: ↑ 5 Changed 7 years ago by duncan

Replying to guest:

I've put a GNU linker first in my PATH! What other way has Cabal to find the "standard" linker?

Run Cabal's configure step with -v and see where it finds ld. Run the build step with -v to see how it actually calls ld during the linking step.

comment:7 Changed 7 years ago by guest

I've added -v to SRC_HC_OPTS and this supports my assumption:

...
*** Linker:
gcc -nostdlib -nodefaultlibs -Wl,-r -Wl,-x -o dist/build/Data/Generics/Basics.
o dist/build/Data/Generics/Basics_split/ld.script
/usr/ccs/bin/ld: illegal option -- x

"Setup configure -v" finds my GNU linker. I could not check if it was used by the build step, but even then it should not fail, because meanwhile I've delete the -x option from Cabal.

comment:8 Changed 7 years ago by duncan

Ah! This one is a GHC bug, and it's independent of the equivalent bug in Cabal.

This is GHC in split-objs mode building the .o file from the collection of _split/*.o files, and it's using -x there.

Ok, so two bugs then. This second does require ghc to check for ld -x in it's configure script.

comment:9 Changed 7 years ago by guest

Yes, two bugs. ghc's configure does check for ld but then uses gcc for linking!

comment:10 Changed 6 years ago by simonmar

  • Owner set to simonmar

comment:11 Changed 6 years ago by simonmar

  • Difficulty changed from Unknown to Moderate (1 day)
  • Milestone changed from 6.8.1 to _|_
  • Owner simonmar deleted

I suggest that since Cabal can now cope with the Solaris linker, that you use this method. Either that or rebuild gcc to use the GNU linker.

Looking at what GHC does, we do make the assumption that ld is the same as the linker that gcc invokes, but removing that assumption is quite tricky. Also, we don't bother re-checking the properties of ld when a binary distribution is installed, so strictly speaking that's another bug. I'll leave this ticket open as documentation, but un-milestone it.

comment:12 follow-up: Changed 6 years ago by guest

gcc does not necessarily use the ld first in PATH. if i recall correctly, the gcc docs describe various routes to find gcc's tools, and on Solaris installs, those tend to be pre-configured to end up with Solaris ld. try 'gcc -print-search-dirs' to see where it is looking before considering PATH, and have a look for GCC_EXEC_PREFIX (which is used before the preconfigured paths). of course, cabal/ghc should really make sure that they use the ld they've configured with:-)

comment:13 in reply to: ↑ 12 Changed 6 years ago by simonmar

Replying to guest:

gcc does not necessarily use the ld first in PATH.

I'm not sure who that reply was directed to, but if it was to me, then I know that gcc doesn't invoke the ld found on PATH. The bug description already gave us the configure options for gcc:

Configured with: ../gcc-4.2.2/configure --prefix=/usr/local/lang -program-suffix=_4.2.2 --enable-64bit --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++

including a specific path for ld.

comment:14 Changed 6 years ago by guest

Ok, a fix is not important. However, it would be nice if ./configure could:

a) also check linking with "gcc -Wl,-x" or

b) check for Solaris-OS (and omit -x then) or

c) allow to set a variable on the configure command line that is passed as flag to the linker

This option would allow to pass "-z redlocsym" to the Solaris linker.

d) I've no idea how important it is to set this linker options at all.

Thanks, Christian.Maeder@…

comment:15 Changed 4 years ago by simonmar

  • Difficulty changed from Moderate (1 day) to Moderate (less than a day)

comment:16 Changed 15 months ago by morabbin

  • Type of failure set to None/Unknown

Bump; is this still of interest?

comment:17 Changed 15 months ago by simonmar

  • Resolution set to worksforme
  • Status changed from new to closed

No activity in 5 years, almost certainly something has changed since then, and AFAIK people are successfully using GHC on Solaris.

Note: See TracTickets for help on using tickets.