On Sun, Jan 26, 2003 at 03:15:28PM -0800, David O'Brien wrote: > On Sat, Jan 25, 2003 at 06:50:08PM +0200, Ruslan Ermilov wrote: > > On Fri, Jan 24, 2003 at 05:54:46PM -0800, Kris Kennaway wrote: > > > On Fri, Jan 24, 2003 at 02:45:44PM -0800, Kris Kennaway wrote: > > > > I'm getting this when trying to cross-build an alpha world. Is anyone > > > > else seeing it? > > > > > > > > cc -O -pipe -DNLIST_ELF64 -static -o crunchide crunchide.o exec_elf64.o > > > > exec_elf64.o: In function `hide_elf64': > > > > exec_elf64.o(.text+0x30b): undefined reference to `be64toh' > > > > exec_elf64.o(.text+0x530): undefined reference to `be64toh' > > > > exec_elf64.o(.text+0x575): undefined reference to `be64toh' > > > > exec_elf64.o(.text+0x59f): undefined reference to `be64toh' > > > > exec_elf64.o(.text+0x5e6): undefined reference to `be64toh' > > > > exec_elf64.o(.text+0x639): more undefined references to `be64toh' follow > > > > *** Error code 1 > > > > > > > > Stop in /a/asami/portbuild/alpha/5/src/usr.sbin/crunch/crunchide. > > > > *** Error code 1 > > > > > > I get the same problem trying to cross-build sparc64. Looks like > > > cross-building is broken. > > > > > This is the result of David O'Brien removing part of my work > > in the quoted commit (see attached), for no apparent reason. > > I gave the reason -- "private version". It is accepted that > duplication on the level of the private endian.h is bad. I made a > change to the system endian.h and found in a manual build of usr.sbin it > wasn't being used. I tracked it down to the private version of endian.h. > The exact details escape me at this time. It appeared to me that you > added the private endian.h because at the time of your commit there > wasn't a system one with the needed bits. > It wasn't entirely private. If you look into it, you'll see this:
#if __FreeBSD_version >= 500034
#include <sys/endian.h>
#else
THE REST
#endif
So the "private" part of this header was only used on systems without
endianness macros in <sys/endian.h>, e.g. RELENG_4 and 5.0-DP1, like
I said.
> So instead of backing out the commit, can we make the cross build work
> with the system version. From the quoted error messages, I don't have
> enough context to know when in the cross 'make world' this is happening.
>
Obviously, this is happening in cross-tools attempting to build crunchide.
You can reproduce it locally:
: Script started on Mon Jan 27 10:04:33 2003
: $ uname -a
: FreeBSD allmouth.sunbay.crimea.ua 4.7-STABLE FreeBSD 4.7-STABLE #59: Sun Jan 5
:15:29:59 EET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERL i386
: $ pwd
: /home/ru/crunch/crunchide
: $ make TARGET_ARCH=sparc64
: Warning: Object directory not changed from original /home/ru/crunch/crunchide
: cc -O -pipe -march=pentiumpro -DNLIST_ELF64 -c crunchide.c
: cc -O -pipe -march=pentiumpro -DNLIST_ELF64 -o crunchide crunchide.o
:exec_elf64.o
: exec_elf64.o: In function `hide_elf64':
: exec_elf64.o(.text+0x317): undefined reference to `be64toh'
: exec_elf64.o(.text+0x544): undefined reference to `be64toh'
: exec_elf64.o(.text+0x589): undefined reference to `be64toh'
: exec_elf64.o(.text+0x5b3): undefined reference to `be64toh'
: exec_elf64.o(.text+0x5fa): undefined reference to `be64toh'
: exec_elf64.o(.text+0x64d): more undefined references to `be64toh' follow
: *** Error code 1
:
: Stop in /home/ru/crunch/crunchide.
: Script done on Mon Jan 27 10:04:45 2003
> > The "private version" of endian.h was smart enough to pick up
> > the system <sys/endian.h> if the latter was fresh enough to
> > have the necessary macros; now it tries to use <sys/endian.h>
> > unconditionally, and fails on systems without be32toh() etc.
> > macros in their <sys/endian.h>, e.g. RELENG_4 or 5.0-DP1.
>
> What are all the cases that things fail now? It looks like you're saying
> (1) doing an Alpha cross-world -CURRENT build on i386, (2) doing a 'make
> buildworld' on -CURRENT sources on a 5.0-DP1 install, (3) doing an
> upgrade from RELENG_4 to HEAD. Is that correct?
>
Upgrades from i386 RELENG_4 to i386 HEAD are unaffected, because
<sys/endian.h> in RELENG_4 has partial (but incomplete, see below)
support for endianness macros, but only for little endian machines,
so if you attempt to upgrade to big endian (sparc64), it is broken.
Even if you attempt to upgrade to little endian but 64bit (alpha),
it is broken, because RELENG_4 <sys/endian.h> misses the be64*()
macros.
As for 5.0-DP1, the upgrades to 5.0-RELEASE are now broken with
this change, because there's no <sys/endian.h> in DP1. Too bad,
I worked really hard on making upgrades to 5.0-RELEASE as painless
as they could be, and I didn't notice this your change in time.
> Perhaps we need the current-compat.h header we've talked about many times
> that we can "cc -include {TOP}/tools/current-compat.h" during the 1st
> stage of 'make buildworld'
>
I think we need to restore the lost functionality first. :-)
This current-compat.h header would presumably be a "union" of
all headers that have __FreeBSD_version stuff in them. Using
this header in a standalone build scenario is very inconvenient.
Sometimes, compatibility stuff is not limited to only headers.
I don't see any problems with my approach. (Remember that
this stuff will go away when we release the first production
quality release on RELENG_5.)
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg50999/pgp00000.pgp
Description: PGP signature
