http://sourceware.org/bugzilla/show_bug.cgi?id=12987
Summary: gold doesn't build on Solaris 11
Product: binutils
Version: 2.22 (HEAD)
Status: NEW
Severity: normal
Priority: P2
Component: gold
AssignedTo: i...@airs.com
ReportedBy: r...@techfak.uni-bielefeld.de
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build: i386-pc-solaris2.11
When retrying to build gold on Solaris 11/x86 this weekend, I ran into a couple
of problems:
* Since gold is built with largefile support, we hit PR c++/30112 when trying
to
the largefile-aware version. I'm using a define to hack around this (patch
attached).
* gold got a bus error even for a trivial link:
> ./ld -Qy -o main /usr/lib/crt1.o /usr/lib/crti.o main.o -lc /usr/lib/crtn.o
Bus Error
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x08531d31 in elfcpp::Sym_write<32, false>::put_st_name (this=0x8044494, v=139)
at /vol/gnu/src/binutils/binutils/local/gold/../elfcpp/elfcpp.h:1323
(gdb) where
#0 0x08531d31 in elfcpp::Sym_write<32, false>::put_st_name (this=0x8044494,
v=139) at /vol/gnu/src/binutils/binutils/local/gold/../elfcpp/elfcpp.h:1323
#1 0x0865bc55 in gold::Symbol_table::sized_write_symbol<32, false>
(this=0x804762c, sym=0x8893da0, value=134513520, shndx=10,
binding=elfcpp::STB_GLOBAL, pool=0x8047464, p=0xfec1070c <Address 0xfec1070c
out of bounds>) at /vol/gnu/src/binutils/binutils/local/gold/symtab.cc:2948
#2 0x08652603 in gold::Symbol_table::sized_write_globals<32, false>
(this=0x804762c, sympool=0x8047464, dynpool=0x80474a8, symtab_xindex=0x0,
dynsym_xindex=0x0, of=0x8936a08) at
/vol/gnu/src/binutils/binutils/local/gold/symtab.cc:2914
#3 0x0864ec35 in gold::Symbol_table::write_globals (this=0x804762c,
sympool=0x8047464, dynpool=0x80474a8, symtab_xindex=0x0, dynsym_xindex=0x0,
of=0x8936a08) at /vol/gnu/src/binutils/binutils/local/gold/symtab.cc:2723
#4 0x0855a7d5 in gold::Write_symbols_task::run (this=0x89383a0) at
/vol/gnu/src/binutils/binutils/local/gold/layout.cc:4921
#5 0x0866a568 in gold::Workqueue::find_and_run_task (this=0x8047918,
thread_number=0) at /vol/gnu/src/binutils/binutils/local/gold/workqueue.cc:319
#6 0x0866aaaa in gold::Workqueue::process (this=0x8047918, thread_number=0) at
/vol/gnu/src/binutils/binutils/local/gold/workqueue.cc:495
#7 0x0842a1dd in main (argc=9, argv=0x80479d4) at
/vol/gnu/src/binutils/binutils/local/gold/main.cc:247
It ultimately turned out that in gold::Output_file *of, of->base_ is invalid.
The issue was that posix_fallocate is unusual in that it returns the error
code on failure, not -1.
* With that corrected, it always failed with EINVAL. It turned out that
Solaris
has a strange (or rather, invalid) interpretation of the POSIX.1 spec here:
its posix_fallocate(3C) states:
EINVAL The len argument is less than or equal to zero, or
the offset argument is less than zero, or the
underlying file system does not support this
operation.
The second part isn't present in POSIX.1, and it turned out that
posix_fallocate resp. the underlying fcntl(F_ALLOCSP) is only supported
on UFS, but there's no indication in the manpage about this. This filesystem
dependence makes the function pretty useless, and I've complained loudly to
the Solaris kernel developers about this. If you always have to provide a
fallback if a particular filesystem doesn't support the functionality, you'd
better do without. For now, I've manually undefined HAVE_POSIX_FALLOCATE
in config.h. Don't what a proper configure test is: even if you happen
to run configure on UFS where this works, you have to deal with the runtime
issue.
* timer.cc didn't compile at first:
/vol/gnu/src/binutils/binutils/local/gold/timer.cc: In constructor
'gold::Timer_init::Timer_init()':
/vol/gnu/src/binutils/binutils/local/gold/timer.cc:75: error: 'sysconf' was not
declared in this scope
I'm including <unistd.h> to fix this.
With those changes, gold compiles and testsuite results are excellent. I'll
report the remaining failures in a separate PR.
One issue I've discovered when using gold in a gcc bootstrap was that its
interpreter was wrong for 64-bit Solaris/x86: there's no /lib/ld64.so.1, but
one needs to use /usr/lib/amd64/ld.so.1 instead, analogously to SPARC.
My hack (doing it in x86_64.cc via __sun__ && __svr4__ tests is of course
wrong: this is a target, not a host issue. One might either handle it in
configure.tgt (changing the value if targetting any *-*-solaris2*) or even
introduce solaris.h along the same line as freebsd.h. As I report shortly,
there are more Solaris differences, so one might want to introduce separate
*_sol2 emulations as I did in gld.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
