The vms linker complains about the 'magic number' of your object module
SIMPLE.O. Use readelf or the vms tool analyze/object to find/compare
what the magic should be - and keep in mind, that on vms object modules
can be concatenated: which means, in an object file the first byte after
an object module is interpreted as the start of the next ELF header:
$ readelf -h shr.obj
ELF Header:
Magic: 7f 45 4c 46 02 01 01 0d 02 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: VMS - OpenVMS
ABI Version: 2
Type: REL (Relocatable file)
Machine: Intel IA-64
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 1648 (bytes into file)
Flags: 0x1000014, 64-bit, vms_linkages
Size of this header: 64 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 64 (bytes)
Number of section headers: 18
Section header string table index: 1
$
On 07/29/2015 10:51 AM, David SAUVAGE - AdaLabs Ltd wrote:
Hi,
Using a crossed native build of binutils running on ia64-hp-openvms,
object file built [2] from assembly file [3] is invalid [1]
As the cross binutils build produces valid object files on the target,
the issue seems to be related to the crossed native build process.
I am looking for hints on how to further investigate and solve this issue.
Best regards,
[1]
||$ MCR DISK$USERS:[ADALABS]ld.exe -v simple.o -o simple.exe
$ link /exe=SIMPLE.EXE simple.opt_tmpfile/opt
|%ILINK-E-INVLDHDR, invalid ELF header; field 'ehdr$b_ei_mag0' has
invalid value
%X00
module: <unassigned>
file: DISK$USERS:[ADALABS]SIMPLE.O;6|
[2]
|$ MCR DISK$USERS:[ADALABS]as.exe -o simple.o simple.s|
[3] simple.s
| .file "simple.c"
.pred.safe_across_calls p1-p5,p16-p63
.text
.align 16
.global main#
.type main#, @function
.proc main#
main:
.prologue 2, 2
.vframe r2
mov r2 = r12
.body
nop 0
;;
.restore sp
mov r12 = r2
br.ret.sptk.many b0
;;
.endp main#
.ident "GCC: (GNU) "|