* RE: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
@ 2006-06-23 15:44 CARTER-HITCHIN, David, GBM
2006-06-23 15:55 ` H. J. Lu
0 siblings, 1 reply; 9+ messages in thread
From: CARTER-HITCHIN, David, GBM @ 2006-06-23 15:44 UTC (permalink / raw)
To: 'binutils@sourceware.org'
Hi,
Looking more closely at the output of --verbose, I've realised that
/usr/lib64/crti.o *is* being linked in, how can I stop ld from doing
that? The info page says that -L paths should override the default
ones, but clearly this is not happening. Should I submit a bug report
or am I missing something?
I could chmod /usr/lib64 to 000 for the duration of the build, but
there has to be a cleaner solution...
Thanks,
David Carter-Hitchin.
--
Royal Bank of Scotland
Interest Rate Derivatives IT
135 Bishopsgate
LONDON EC2M 3TP
Tel: +44 (0) 207 085 1088
> -----Original Message-----
> From: CARTER-HITCHIN, David, GBM
> Sent: 22 June 2006 13:16
> To: 'binutils@sourceware.org'
> Subject: Compiling and linking 32 bit code on a 64 machine
> (AMD Opteron)
>
>
> Hi,
>
> I'm not sure if this is a GCC question or a GNU ld question
> (or both), so I'll try here first. I'm trying to compile and
> link a C/C++ project on an Opteron RHEL AS-3 machine, as 32
> bit. I've compiled GCC 3.4.6 and binutils (both bootstrapped
> from the compiler that came with the machine), and I've given
> the following options to GCC/LD:
>
> GCC: -march=i386 -m32
> LD: --format elf32-i686 -m elf_i386
>
> I also have some -Lpath switches to pick up the 32 bit
> libraries. Interestingly, at one point, ld tries to find
> libgcc_s.so, but can't find it. It does find the 64 bit
> version under my GCC 3.4.6 installation, but can't find the
> 32 bit one because that's called libgcc_s.so.1 - there is a
> symlink called libgcc_s_32.so to libgcc_s.so.1, but nothing
> called libgcc_s.so here, so I created a link called that to
> point to libgcc_s.so.1. Perhaps that is a GCC question, but
> did I do the Right Thing(tm)?
>
> Now the whole project compiles and links, but there are two
> problems - one is just annoying, the other fatal:
>
> a) The first problem is that every time the linker runs it
> generates warnings, as it first finds, for example, crti.o in
> '/usr/lib/../lib64/crti.o'. Now I've put -L/usr/lib as an
> option to ld, and the info pages say these directories will
> be searched before the default paths, but that doesn't appear
> to be happening - /usr/lib64 is still in the mix. I ran ld
> with --verbose and the SEARCH_DIRs do not include /usr/lib64.
>
> b) Secondly, when I run one of the resulting binaries it
> fails horribly:
>
> ksh: path/to/binary: Accessing a corrupted shared library
>
> file <binary> shows:
>
> ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
> GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped.
>
> How can I tell which library is causing this? Can some kind
> soul shed some light on these problems? Perhaps I'm using
> the wrong options to begin with - I tried to google for this,
> but didn't find any specific information for what I'm trying
> to achieve. This post is already quite long, so I won't post
> any more detail such as --verbose output, unless someone asks.
>
> Many thanks,
>
> David Carter-Hitchin.
> --
> Royal Bank of Scotland
> Interest Rate Derivatives IT
> 135 Bishopsgate
> LONDON EC2M 3TP
>
> Tel: +44 (0) 207 085 1088
>
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorized and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbos.com
http://www.rbsmarkets.com
***********************************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
2006-06-23 15:44 Compiling and linking 32 bit code on a 64 machine (AMD Optero n) CARTER-HITCHIN, David, GBM
@ 2006-06-23 15:55 ` H. J. Lu
0 siblings, 0 replies; 9+ messages in thread
From: H. J. Lu @ 2006-06-23 15:55 UTC (permalink / raw)
To: CARTER-HITCHIN, David, GBM; +Cc: 'binutils@sourceware.org'
On Fri, Jun 23, 2006 at 04:36:11PM +0100, CARTER-HITCHIN, David, GBM wrote:
> Hi,
>
> Looking more closely at the output of --verbose, I've realised that
> /usr/lib64/crti.o *is* being linked in, how can I stop ld from doing
> that? The info page says that -L paths should override the default
> ones, but clearly this is not happening. Should I submit a bug report
> or am I missing something?
>
It shouldn't happen. Please provide a complete testcase to show what
really happened.
H.J.
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
@ 2006-06-23 16:59 CARTER-HITCHIN, David, GBM
2006-06-23 17:21 ` H. J. Lu
0 siblings, 1 reply; 9+ messages in thread
From: CARTER-HITCHIN, David, GBM @ 2006-06-23 16:59 UTC (permalink / raw)
To: 'H. J. Lu'; +Cc: 'binutils@sourceware.org'
Hi HJ
Thanks for replying.
I've built a testcase: I've got a 6 line Makefile, a 5 line helloworld
source file and 238 lines of linker output. Shall I post those here, or is
there a better place?
Thanks,
David Carter-Hitchin.
--
Royal Bank of Scotland
Interest Rate Derivatives IT
135 Bishopsgate
LONDON EC2M 3TP
Tel: +44 (0) 207 085 1088
> -----Original Message-----
> From: H. J. Lu [mailto:hjl@lucon.org]
> Sent: 23 June 2006 16:45
> To: CARTER-HITCHIN, David, GBM
> Cc: 'binutils@sourceware.org'
> Subject: Re: Compiling and linking 32 bit code on a 64
> machine (AMD Optero n)
>
>
> On Fri, Jun 23, 2006 at 04:36:11PM +0100, CARTER-HITCHIN,
> David, GBM wrote:
> > Hi,
> >
> > Looking more closely at the output of --verbose, I've realised that
> > /usr/lib64/crti.o *is* being linked in, how can I stop ld from doing
> > that? The info page says that -L paths should override the default
> > ones, but clearly this is not happening. Should I submit a
> bug report
> > or am I missing something?
> >
>
> It shouldn't happen. Please provide a complete testcase to show what
> really happened.
>
>
> H.J.
>
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorized and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbos.com
http://www.rbsmarkets.com
***********************************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
2006-06-23 16:59 CARTER-HITCHIN, David, GBM
@ 2006-06-23 17:21 ` H. J. Lu
0 siblings, 0 replies; 9+ messages in thread
From: H. J. Lu @ 2006-06-23 17:21 UTC (permalink / raw)
To: CARTER-HITCHIN, David, GBM; +Cc: 'binutils@sourceware.org'
On Fri, Jun 23, 2006 at 05:45:33PM +0100, CARTER-HITCHIN, David, GBM wrote:
> Hi HJ
>
> Thanks for replying.
>
> I've built a testcase: I've got a 6 line Makefile, a 5 line helloworld
> source file and 238 lines of linker output. Shall I post those here, or is
> there a better place?
>
Please post it here.
H.J.
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
@ 2006-06-23 17:28 CARTER-HITCHIN, David, GBM
2006-06-23 17:30 ` Daniel Jacobowitz
2006-06-23 18:12 ` H. J. Lu
0 siblings, 2 replies; 9+ messages in thread
From: CARTER-HITCHIN, David, GBM @ 2006-06-23 17:28 UTC (permalink / raw)
To: 'H. J. Lu'; +Cc: 'binutils@sourceware.org'
Hi,
> Please post it here.
Here is is:
[]-> uname -a
Linux lon3315xus 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:46:36 EDT 2005
x86_64 x86_64 x86_64 GNU/Linux
[]-> cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 7)
[]-> g++ -v
Reading specs from
/apps/IRDtools/pkgs/pd/gcc/3.4.1/p4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/s
pecs
Configured with: /usr/local/build/gcc-3.4.1/configure
--prefix=/opt/GDStools/pkgs/pd/gcc/3.4.1/p4 --enable-threads
--enable-languages=c,c++
Thread model: posix
gcc version 3.4.1
[lon3315xus]-> ld --version
GNU ld version 2.16
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
[]-> cat hello.cpp
#include <iostream>
int main () {
std::cout << "hello, world\n";
}
[]-> cat Makefile
hello: hello.o
g++ -Wl,--verbose -Wl,-L,/usr/lib -Wl,--format,elf32-i386
-Wl,-m,elf_i386 -o hello
-L/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6
/32 -L/usr/lib
hello.o:
g++ -fPIC -Wall -Werror -Wno-sign-compare -march=i386 -m32 -c
hello.cpp -o hello.o
make > output 2>&1
cat output
g++ -Wl,--verbose -Wl,-L,/usr/lib -Wl,--format,elf32-i386 -Wl,-m,elf_i386 -o
hello
-L/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6
/32 -L/usr/lib
GNU ld version 2.16
Supported emulations:
elf_x86_64
elf_i386
i386linux
using internal linker script:
==================================================
/* Script for -z combreloc: combine and sort reloc sections */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/i386-unknown-linux-
gnu/lib"); SEARCH_DIR("/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/lib");
SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
/* Do we need any of these for elf?
__DYNAMIC = 0; */
SECTIONS
{
/* Read-only sections, merged into text segment: */
PROVIDE (__executable_start = 0x08048000); . = 0x08048000 +
SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.dyn :
{
*(.rel.init)
*(.rel.text .rel.text.* .rel.gnu.linkonce.t.*)
*(.rel.fini)
*(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*)
*(.rel.data.rel.ro*)
*(.rel.data .rel.data.* .rel.gnu.linkonce.d.*)
*(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*)
*(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*)
*(.rel.ctors)
*(.rel.dtors)
*(.rel.got)
*(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*)
}
.rela.dyn :
{
*(.rela.init)
*(.rela.text .rela.text.* .rela.gnu.linkonce.t.*)
*(.rela.fini)
*(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*)
*(.rela.data .rela.data.* .rela.gnu.linkonce.d.*)
*(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*)
*(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*)
*(.rela.ctors)
*(.rela.dtors)
*(.rela.got)
*(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*)
}
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init :
{
KEEP (*(.init))
} =0x90909090
.plt : { *(.plt) }
.text :
{
*(.text .stub .text.* .gnu.linkonce.t.*)
KEEP (*(.text.*personality*))
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
} =0x90909090
.fini :
{
KEEP (*(.fini))
} =0x90909090
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
.rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) }
.rodata1 : { *(.rodata1) }
.eh_frame_hdr : { *(.eh_frame_hdr) }
.eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table))
*(.gcc_except_table.*) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1)); . = DATA_SEGMENT_ALIGN
(0x1000, 0x1000);
/* Exception handling */
.eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) }
.gcc_except_table : ONLY_IF_RW { KEEP (*(.gcc_except_table))
*(.gcc_except_table.*) }
/* Thread Local Storage sections */
.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
.tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
/* Ensure the __preinit_array_start label is properly aligned. We
could instead move the label definition inside the section, but
the linker would then create the section even if it turns out to
be empty, which isn't pretty. */
. = ALIGN(32 / 8);
PROVIDE (__preinit_array_start = .);
.preinit_array : { KEEP (*(.preinit_array)) }
PROVIDE (__preinit_array_end = .);
PROVIDE (__init_array_start = .);
.init_array : { KEEP (*(.init_array)) }
PROVIDE (__init_array_end = .);
PROVIDE (__fini_array_start = .);
.fini_array : { KEEP (*(.fini_array)) }
PROVIDE (__fini_array_end = .);
.ctors :
{
/* gcc uses crtbegin.o to find the start of
the constructors, so we make sure it is
first. Because this is a wildcard, it
doesn't matter if the user does not
actually link against crtbegin.o; the
linker won't look for a file to match a
wildcard. The wildcard also means that it
doesn't matter which directory crtbegin.o
is in. */
KEEP (*crtbegin*.o(.ctors))
/* We don't want to include the .ctor section from
from the crtend.o file until after the sorted ctors.
The .ctor section from the crtend file contains the
end of ctors marker and it must be last */
KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors))
KEEP (*(SORT(.ctors.*)))
KEEP (*(.ctors))
}
.dtors :
{
KEEP (*crtbegin*.o(.dtors))
KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors))
KEEP (*(SORT(.dtors.*)))
KEEP (*(.dtors))
}
.jcr : { KEEP (*(.jcr)) }
.data.rel.ro : { *(.data.rel.ro.local) *(.data.rel.ro*) }
.dynamic : { *(.dynamic) }
.got : { *(.got) }
. = DATA_SEGMENT_RELRO_END (12, .);
.got.plt : { *(.got.plt) }
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
KEEP (*(.gnu.linkonce.d.*personality*))
SORT(CONSTRUCTORS)
}
.data1 : { *(.data1) }
_edata = .;
PROVIDE (edata = .);
__bss_start = .;
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections. */
. = ALIGN(32 / 8);
}
. = ALIGN(32 / 8);
_end = .;
PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section so we begin them at 0. */
/* DWARF 1 */
.debug 0 : { *(.debug) }
.line 0 : { *(.line) }
/* GNU DWARF 1 extensions */
.debug_srcinfo 0 : { *(.debug_srcinfo) }
.debug_sfnames 0 : { *(.debug_sfnames) }
/* DWARF 1.1 and DWARF 2 */
.debug_aranges 0 : { *(.debug_aranges) }
.debug_pubnames 0 : { *(.debug_pubnames) }
/* DWARF 2 */
.debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) }
.debug_abbrev 0 : { *(.debug_abbrev) }
.debug_line 0 : { *(.debug_line) }
.debug_frame 0 : { *(.debug_frame) }
.debug_str 0 : { *(.debug_str) }
.debug_loc 0 : { *(.debug_loc) }
.debug_macinfo 0 : { *(.debug_macinfo) }
/* SGI/MIPS DWARF 2 extensions */
.debug_weaknames 0 : { *(.debug_weaknames) }
.debug_funcnames 0 : { *(.debug_funcnames) }
.debug_typenames 0 : { *(.debug_typenames) }
.debug_varnames 0 : { *(.debug_varnames) }
/DISCARD/ : { *(.note.GNU-stack) }
}
==================================================
attempt to open /usr/lib/../lib64/crt1.o succeeded
/usr/lib/../lib64/crt1.o
attempt to open /usr/lib/../lib64/crti.o succeeded
/usr/lib/../lib64/crti.o
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/c
rtbegin.o succeeded
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/c
rtbegin.o
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc.so failed
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc.a succeeded
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc_eh.so failed
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc_eh.a succeeded
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libc.so failed
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libc.a failed
att/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/bin/ld: warning: i386:x86-64
architecture of input file `/usr/lib/../lib64/crt1.o' is incompatible with
i386 output
/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/bin/ld: warning: i386:x86-64
architecture of input file `/usr/lib/../lib64/crti.o' is incompatible with
i386 output
/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/bin/ld: warning: i386:x86-64
architecture of input file
`/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/
crtbegin.o' is incompatible with i386 output
/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/bin/ld: warning: i386:x86-64
architecture of input file
`/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/
crtend.o' is incompatible with i386 output
/apps/IRDtools/pkgs/pd/binutils/2.16-opteron/bin/ld: warning: i386:x86-64
architecture of input file `/usr/lib/../lib64/crtn.o' is incompatible with
i386 output
/usr/lib/../lib64/crt1.o: In function `_start':
: undefined reference to `main'
empt to open /usr/lib/libc.so succeeded
opened script file /usr/lib/libc.so
opened script file /usr/lib/libc.so
attempt to open /lib/libc.so.6 succeeded
/lib/libc.so.6
attempt to open /usr/lib/libc_nonshared.a succeeded
(/usr/lib/libc_nonshared.a)elf-init.oS
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc.so failed
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc.a succeeded
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc_eh.so failed
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/3
2/libgcc_eh.a succeeded
attempt to open
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/c
rtend.o succeeded
/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6/c
rtend.o
attempt to open /usr/lib/../lib64/crtn.o succeeded
/usr/lib/../lib64/crtn.o
ld-linux.so.2 needed by /lib/libc.so.6
found ld-linux.so.2 at /lib/ld-linux.so.2
collect2: ld returned 1 exit status
make: *** [hello] Error 1
What is odd is that it is accessing /usr/lib64 from /usr/lib/../lib64.
Perhaps this is a clue as to what is going wrong?
Thanks,
David.
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorized and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbos.com
http://www.rbsmarkets.com
***********************************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
2006-06-23 17:28 CARTER-HITCHIN, David, GBM
@ 2006-06-23 17:30 ` Daniel Jacobowitz
2006-06-23 18:12 ` H. J. Lu
1 sibling, 0 replies; 9+ messages in thread
From: Daniel Jacobowitz @ 2006-06-23 17:30 UTC (permalink / raw)
To: CARTER-HITCHIN, David, GBM
Cc: 'H. J. Lu', 'binutils@sourceware.org'
On Fri, Jun 23, 2006 at 06:21:08PM +0100, CARTER-HITCHIN, David, GBM wrote:
> g++ -Wl,--verbose -Wl,-L,/usr/lib -Wl,--format,elf32-i386
> -Wl,-m,elf_i386 -o hello
> -L/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6
> /32 -L/usr/lib
Did you see my reply, where I explained why this was wrong?
http://sourceware.org/ml/binutils/2006-06/msg00334.html
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
2006-06-23 17:28 CARTER-HITCHIN, David, GBM
2006-06-23 17:30 ` Daniel Jacobowitz
@ 2006-06-23 18:12 ` H. J. Lu
1 sibling, 0 replies; 9+ messages in thread
From: H. J. Lu @ 2006-06-23 18:12 UTC (permalink / raw)
To: CARTER-HITCHIN, David, GBM; +Cc: 'binutils@sourceware.org'
On Fri, Jun 23, 2006 at 06:21:08PM +0100, CARTER-HITCHIN, David, GBM wrote:
> Hi,
>
> > Please post it here.
>
> Here is is:
>
> []-> uname -a
> Linux lon3315xus 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:46:36 EDT 2005
> x86_64 x86_64 x86_64 GNU/Linux
> []-> cat /etc/redhat-release
> Red Hat Enterprise Linux AS release 3 (Taroon Update 7)
>
> []-> g++ -v
> Reading specs from
> /apps/IRDtools/pkgs/pd/gcc/3.4.1/p4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.1/s
> pecs
> Configured with: /usr/local/build/gcc-3.4.1/configure
> --prefix=/opt/GDStools/pkgs/pd/gcc/3.4.1/p4 --enable-threads
> --enable-languages=c,c++
> Thread model: posix
> gcc version 3.4.1
> [lon3315xus]-> ld --version
> GNU ld version 2.16
> Copyright 2005 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License. This program has absolutely no warranty.
>
>
> []-> cat hello.cpp
> #include <iostream>
>
> int main () {
> std::cout << "hello, world\n";
> }
>
>
> []-> cat Makefile
> hello: hello.o
> g++ -Wl,--verbose -Wl,-L,/usr/lib -Wl,--format,elf32-i386
> -Wl,-m,elf_i386 -o hello
> -L/apps/IRDtools/pkgs/pd/gcc/3.4.6/o1/lib/gcc/x86_64-unknown-linux-gnu/3.4.6
> /32 -L/usr/lib
>
Please use
g++ -Wl,--verbose -m32 -o hello hello.o
H.J.
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
@ 2006-06-23 23:01 CARTER-HITCHIN, David, GBM
0 siblings, 0 replies; 9+ messages in thread
From: CARTER-HITCHIN, David, GBM @ 2006-06-23 23:01 UTC (permalink / raw)
To: 'Daniel Jacobowitz'
Cc: 'H. J. Lu', 'binutils@sourceware.org'
> Did you see my reply, where I explained why this was wrong?
>
> http://sourceware.org/ml/binutils/2006-06/msg00334.html
I'm very sorry I did not, for some reason. This was the exact problem,
thank you very much indeed for your help.
Regards,
David.
--
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorized and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbos.com
http://www.rbsmarkets.com
***********************************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)
@ 2006-06-23 23:11 CARTER-HITCHIN, David, GBM
0 siblings, 0 replies; 9+ messages in thread
From: CARTER-HITCHIN, David, GBM @ 2006-06-23 23:11 UTC (permalink / raw)
To: 'H. J. Lu'; +Cc: 'binutils@sourceware.org'
>
> Please use
>
> g++ -Wl,--verbose -m32 -o hello hello.o
>
>
> H.J.
>
Bingo! As I just said to Daniel Jacobowitz, this was the fix I was looking
for.
Many thanks for your help,
David.
--
***********************************************************************************
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Authorized and regulated by the Financial Services Authority
This e-mail message is confidential and for use by the
addressee only. If the message is received by anyone other
than the addressee, please return the message to the sender
by replying to it and then delete the message from your
computer. Internet e-mails are not necessarily secure. The
Royal Bank of Scotland plc does not accept responsibility for
changes made to this message after it was sent.
Whilst all reasonable care has been taken to avoid the
transmission of viruses, it is the responsibility of the recipient to
ensure that the onward transmission, opening or use of this
message and any attachments will not adversely affect its
systems or data. No responsibility is accepted by The Royal
Bank of Scotland plc in this regard and the recipient should carry
out such virus and other checks as it considers appropriate.
Visit our websites at:
http://www.rbos.com
http://www.rbsmarkets.com
***********************************************************************************
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-06-23 23:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-23 15:44 Compiling and linking 32 bit code on a 64 machine (AMD Optero n) CARTER-HITCHIN, David, GBM
2006-06-23 15:55 ` H. J. Lu
2006-06-23 16:59 CARTER-HITCHIN, David, GBM
2006-06-23 17:21 ` H. J. Lu
2006-06-23 17:28 CARTER-HITCHIN, David, GBM
2006-06-23 17:30 ` Daniel Jacobowitz
2006-06-23 18:12 ` H. J. Lu
2006-06-23 23:01 CARTER-HITCHIN, David, GBM
2006-06-23 23:11 CARTER-HITCHIN, David, GBM
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).