Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2012-11

Solaris and binutils 2.22 break fpc linking and workaround

3 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Helmut Hartl

Hi,

While building under SmartOS in a buildzone
(IllumOS, former OpenSolaris) i have the problem that with binutils 2.22 the fpc generated linker script line in ppas.sh

/opt/local/bin/gld -melf_x86_64 -s -L. -o my_program link.res

is not working anymore. Because the only targets the new binutils 2.22 support on solaris are elf_x86_64_sol2 and elf_i386_sol2.

Manually linking with: (after compiling with -Cn)

$/opt/local/bin/gld -melf_x86_64_sol2 -s -L. -o fpmake_packages link.res

is working!

Others have similar problems on gentoo:
http://archives.gentoo.org/gentoo-alt/msg_a4641a1c17ce5f66a05c6440dd5cfc87.xml

The problem is that on SmartOS the build machines and packages default to gcc47 with binutils 2.22.

I "fixed" it for me by compiling the compiler only on Openindiana 151a7 (older binutils) with the following applied trivial patch, and copying the resulting compiler(s) (32/64) bit to the
target system. A full build for a 32 bit and a 64 bit fpc went well.

--- ./systems/t_sunos.pas.bak   2012-08-27 12:24:46.000000000 +0200
+++ ./systems/t_sunos.pas       2012-11-04 05:59:23.399713956 +0100
@@ -143,12 +143,12 @@
  }
  {$ifdef x86_64}
  const
-  gld = 'gld -m elf_x86_64 ';
+  gld = 'gld -m elf_x86_64_sol2 ';
    solaris_ld = '/usr/bin/ld -64 ';
  {$endif}
  {$ifdef i386}
  const
-  gld = 'gld ';
+  gld = 'gld -m elf_i386_sol2 ';
    solaris_ld = '/usr/bin/ld ';
  {$endif }
  {$ifdef sparc}

What are the options to fix this properly ?
I did not manage to get it working with the existing comand line options.I think it is needed to influence the -m option which fpc generates in "t_sunos", depending on an switch stating the usage of binutils greater than
a certain version.

helmut

Reply by email

Pierre Free Pascal
to Helmut Hartl

On the VM I have access to:

gld --help | grep -i emul
-m EMULATION Set emulation
-V Print version and emulation information gld: supported emulations: elf_i386_ldso elf_i386 elf_x86_64 gld: emulation specific options:

gld --version
GNU ld (GNU Binutils) 2.19
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

This is pretty bad...
2.19 is not that old, and it doesn't even know about elf_x86_64_sol2 emulation...
I tested it by manually changing elf_x86_64 into elf_x86_64_sol2 in a ppas.sh script generated with -s option...

Until now, we always managed to avoid
parsing the output of a 'ld --version'
to adapt the command line, but here I have no idea how we could do it without something like that :(

Pierre Muller

Show quoted text 68 lines
-----Message d'origine----- De : [mailto:fpc-devel- De la part de Helmut Hartl Envoyé : mardi 20 novembre 2012 14:52 À : FPC developers' list Objet : [fpc-devel] Solaris and binutils 2.22 break fpc linking and workaround Hi, While building under SmartOS in a buildzone (IllumOS, former OpenSolaris) i have the problem that with binutils 2.22 the fpc generated linker script line in ppas.sh /opt/local/bin/gld -melf_x86_64 -s -L. -o my_program link.res is not working anymore. Because the only targets the new binutils 2.22 support on solaris are elf_x86_64_sol2 and elf_i386_sol2. Manually linking with: (after compiling with -Cn) $/opt/local/bin/gld -melf_x86_64_sol2 -s -L. -o fpmake_packages link.res is working! Others have similar problems on gentoo: http://archives.gentoo.org/gentoo- alt/msg_a4641a1c17ce5f66a05c6440dd5cfc87.xml The problem is that on SmartOS the build machines and packages default to gcc47 with binutils 2.22. I "fixed" it for me by compiling the compiler only on Openindiana 151a7 (older binutils) with the following applied trivial patch, and copying the resulting compiler(s) (32/64) bit to the target system. A full build for a 32 bit and a 64 bit fpc went well. --- ./systems/t_sunos.pas.bak 2012-08-27 12:24:46.000000000 +0200 +++ ./systems/t_sunos.pas 2012-11-04 05:59:23.399713956 +0100 @@ -143,12 +143,12 @@ } {$ifdef x86_64} const - gld = 'gld -m elf_x86_64 '; + gld = 'gld -m elf_x86_64_sol2 '; solaris_ld = '/usr/bin/ld -64 '; {$endif} {$ifdef i386} const - gld = 'gld '; + gld = 'gld -m elf_i386_sol2 '; solaris_ld = '/usr/bin/ld '; {$endif } {$ifdef sparc} What are the options to fix this properly ? I did not manage to get it working with the existing comand line options.I think it is needed to influence the -m option which fpc generates in "t_sunos", depending on an switch stating the usage of binutils greater than a certain version. helmut _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jonas Maebe
to Helmut Hartl: While building under SmartOS in a buildzone (IllumOS, former OpenSolaris) i have the…
Helmut Hartl wrote 8 lines
While building under SmartOS in a buildzone (IllumOS, former OpenSolaris) i have the problem that with binutils 2.22 the fpc generated linker script line in ppas.sh /opt/local/bin/gld -melf_x86_64 -s -L. -o my_program link.res is not working anymore. Because the only targets the new binutils 2.22 support on solaris are elf_x86_64_sol2 and elf_i386_sol2.

That's probably "supported by default". I'm sure it's possible to still build a binutils version that still supports regular elf_x86_64.

My suggestion would be to simply change the compiler to always use elf_x86_64_sol2/elf_i386_sol2 and require binutils 2.21 or higher on Solaris. It's not like there is a massive user base for that platform, nor very old Solaris/x86 systems that will have trouble supporting newer binutils versions.

Apparently the Solaris ABI is in fact different from the regular x86 ELF abi, which is why that change was made in the first place. So the programs generated with -melf_x86_64/-m-melf_i386 were not properly ABI-compliant in the first place.

Jonas

Reply by email