This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Compiling and linking 32 bit code on a 64 machine (AMD Optero n)


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...


David Carter-Hitchin.
Royal Bank of Scotland
Interest Rate Derivatives IT
135 Bishopsgate

Tel: +44 (0) 207 085 1088

> -----Original Message-----
> Sent: 22 June 2006 13:16
> To: ''
> 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 
>, 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 - there is a 
> symlink called to, but nothing 
> called here, so I created a link called that to 
> point to  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
> 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: 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]