Bug 112215 - [patch] [amd64] gcc(1): "gcc -m32" attempts to link against 64-bit libs
Summary: [patch] [amd64] gcc(1): "gcc -m32" attempts to link against 64-bit libs
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: gnu (show other bugs)
Version: 6.2-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Eitan Adler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-28 22:40 UTC by Peter Jeremy
Modified: 2012-05-07 05:02 UTC (History)
0 users

See Also:


Attachments
file.diff (702 bytes, patch)
2007-04-28 22:40 UTC, Peter Jeremy
no flags Details | Diff
file.diff (1.48 KB, patch)
2007-04-28 22:40 UTC, Peter Jeremy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Jeremy 2007-04-28 22:40:05 UTC
	"gcc -m32" correctly builds 32-bit objects but attempts to use
	64-bit libraries and the 64-bit dynamic loader when linking.

Fix: A work-around is to install /usr/libdata/gcc/specs which is
	"gcc -dumpspecs" with the following patch:
A complete fix is less clear.  *fbsd_dynamic_linker is derived from
	FBSD_DYNAMIC_LINKER - which is currently common across all FreeBSD
	platforms.  (Note that the code for FBSD_MAJOR<5 is obsolete now).
	Likewise *startfile_prefix_spec is common.  The following (untested)
	patch should work:
How-To-Repeat: 	echo 'main(){printf("Hello world\\n");}' > x.c
	gcc -v -m32 x.c

	Note that whilst it correctly passes "-m elf_i386_fbsd" to ld,
	it specifies /libexec/ld-elf.so.1 instead of /libexec/ld-elf32.so.1
	and /usr/lib/... instead of /usr/lib32/...
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2007-04-29 00:04:06 UTC
Responsible Changed
From-To: freebsd-amd64->kan

kan, can you take a look at this one please?
Comment 2 Peter Jeremy 2007-04-29 11:55:23 UTC
On 2007-Apr-29 07:35:40 +1000, Peter Jeremy <peterjeremy@optushome.com.au> wrote:
>	Note that whilst it correctly passes "-m elf_i386_fbsd" to ld,
>	it specifies /libexec/ld-elf.so.1 instead of /libexec/ld-elf32.so.1
>	and /usr/lib/... instead of /usr/lib32/...
>
>>Fix:
>	A work-around is to install /usr/libdata/gcc/specs which is
>	"gcc -dumpspecs" with the following patch:


Note that one disadvantage of the patches I proposed is that i386
executables built on amd64 won't run on i386.  This is because the
executables reference /libexec/ld-elf32.so.1 and /usr/lib32/*.so -
which don't exist on an i386 install.  The solutions here would seem
to be:
a) link /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 and /usr/lib to
   /usr/lib32 on i386 (though this doesn't work for libc.so.N which is
   in /lib)
b) Use a different fix to amd64/112215 that links the executables in
   "compatibility" mode (in much the same way as i386 executables can
   point to /libexec/ld-elf.so.1 and /usr/lib but still run on amd64).

The second approach would seem cleaner (ie an i386 executable looks
identical whether it was built natively on i386 or using -m32 on
amd64) but I'm not sure how easy it is to implement.  The first
approach is basically implementing "i386 emulation" mode on i386.

-- 
Peter Jeremy
Comment 3 Alexander Kabaev freebsd_committer freebsd_triage 2007-04-29 16:44:38 UTC
State Changed
From-To: open->suspended

Cross build for 32 bit is plan not supported on amd64 due to many reasons, 
gcc specs being the least serious of them. 

We do not not install correct machine/ headers anywhere, so any binary 
compiled with -m32 still refers to amd64's machine/*.h headers. 

Ther patch makes no sense until we have cross-environment to speak of 
in the first place. 



Comment 4 Alexander Kabaev freebsd_committer freebsd_triage 2007-04-29 16:44:38 UTC
Responsible Changed
From-To: kan->freebsd-amd64

Cross build for 32 bit is plan not supported on amd64 due to many reasons, 
gcc specs being the least serious of them. 

We do not not install correct machine/ headers anywhere, so any binary 
compiled with -m32 still refers to amd64's machine/*.h headers. 

Ther patch makes no sense until we have cross-environment to speak of 
in the first place.
Comment 5 David E. O'Brien freebsd_committer freebsd_triage 2008-02-05 17:57:51 UTC
Responsible Changed
From-To: freebsd-amd64->obrien

I'll keep an eye on this -but I think we're going to close it as 
simply not supported at this time.
Comment 6 Mark Linimon 2011-03-09 20:54:04 UTC
----- Forwarded message from Thomas David Rivers <rivers@dignus.com> -----

Date: Wed, 09 Mar 2011 15:15:39 -0500
From: Thomas David Rivers <rivers@dignus.com>
To: freebsd-stable@freebsd.org
Subject: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)?
User-Agent: Heirloom mailx 12.4 7/29/08

Just installed a fresh 8.2-stable on a brand-spanking-new 64-bit
machine...

But, when I try to build 32-bit programs I get problems linking,
and I stumbled onto PR bin/139146.  [bugmeister note: closed as
a duplicate of 112215, so followup redirected there.]

The PR mentions this quick test:

  uname -sr && echo "int main () { }" > t.c && gcc -v --help 2>&1 | grep m32 && gcc -m32 t.c

which I try to get this output:

FreeBSD 8.2-RELEASE
  -m32                        Generate 32bit i386 code
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc
/usr/bin/ld: skipping incompatible /usr/lib/libgcc.a when searching for -lgcc
/usr/bin/ld: cannot find -lgcc


So - I'm wondering what the proper approach is on amd64 to build 
32-bit applications?

	- Thanks! -
	- Dave Rivers -

--
rivers@dignus.com                        Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com



_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


----- End forwarded message -----
Comment 7 Eitan Adler freebsd_committer freebsd_triage 2012-05-07 05:00:48 UTC
State Changed
From-To: suspended->closed

quick test works for me
Comment 8 Eitan Adler freebsd_committer freebsd_triage 2012-05-07 05:02:08 UTC
Responsible Changed
From-To: obrien->eadler

I closed it.