headers
Nick Moffitt | 1 Aug 2003 03:37

bug#342: we need to make glibc's autoconf believe that it should cross-compile

So I have been in correspondance with Daniel Jacobowitz, and he has
given some great advice.  He says that modern autoconf builds key off
of differences between --host and --build.  Since both of ours are
x86, it figures it doesn't need to bother with cross-compiling, and
makes too many assumptions about what is native.

He suggested the following examples for ways to trick autoconf into
taking the cross-compile path, which keeps glibc from doing locales
and rpcgen and lots of other bulky time-consuming stuff that we really
don't want anyway:

  ../src/configure --build=i386-pc-linux-gnu --host=i686-pc-linux-gnu
  ../src/configure --build=i686-mydesktop-linux-gnu --host=i686-pc-linux-gnu
  ../src/configure --build=i686-monkeys-linux-gnu --host=i686-bananas-linux-gnu

The --host one will show up in the built glibc, so we should probably
choose it carefully, like --host=i386-lnxbbc-linux-gnu or something.

--

-- 

end

 Support your droogs!
Permalink | Reply | 0 comments |
headers
Nick Moffitt | 1 Aug 2003 03:49

bug#342: bug#342: we need to make glibc's autoconf believe that it should cross-compile

We've been using "i386-linux" and "i386-pc-linux-gnu" as strings.  As
Daniel clued me into:

[nick <at> gargoyle(~/gar/devel/glibc/work/main.d/glibc-2.2.5/scripts)] ./config.sub i386-linux
i386-pc-linux-gnu

The one gets expanded to the other!  

Inkblot suggests i386-lnxbbc-linux:

[inkblot <at> gargoyle:~/var/src/gar/devel/glibc/work/singularity.d/glibc-2.3.1]$
./scripts/config.sub i386-lnxbbc-linux
i386-lnxbbc-linux-gnu

I would tend to concur.

--

-- 

end

 Support your droogs!
Permalink | Reply | 3 comments |
headers
Seth David Schoen | 1 Aug 2003 04:17

bug#342: [Lnx-bbc-devel] Re: bug#342: we need to make glibc's autoconf believe that it should cross-compile

Nick Moffitt writes:

> We've been using "i386-linux" and "i386-pc-linux-gnu" as strings.  As
> Daniel clued me into:
> 
> [nick <at> gargoyle(~/gar/devel/glibc/work/main.d/glibc-2.2.5/scripts)] ./config.sub i386-linux
> i386-pc-linux-gnu
> 
> The one gets expanded to the other!  
> 
> Inkblot suggests i386-lnxbbc-linux:
> 
> [inkblot <at> gargoyle:~/var/src/gar/devel/glibc/work/singularity.d/glibc-2.3.1]$
./scripts/config.sub i386-lnxbbc-linux
> i386-lnxbbc-linux-gnu
> 
> I would tend to concur.

If we do this, is there any problem in using (a) our gcc, (b) our
binutils, or (c) our glibc to build things (1) in our gar tree to run
on the BBC, (2) on the BBC to run on the BBC, (3) on the BBC to run on
another host system?

I would not be offended if the answer to some of those were "mu".

I'm assuming that this arch string does not affect the actual binary
format of anything, but I wonder if it can confuse configure scripts
or tools run from configure scripts.  If only I were able to take
Nick's tutorial, I'm sure my confusion about these effects would be
cleared up quickly.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Moffitt | 1 Aug 2003 04:54

bug#342: Lnx-bbc-devel] Re: bug#342: we need to make glibc's autoconf believe that it should cross-compile

begin  The ASCII Floating Head of Seth David Schoen  quotation:
> If we do this, is there any problem in using (a) our gcc, (b) our
> binutils, or (c) our glibc to build things (1) in our gar tree to
> run on the BBC, (2) on the BBC to run on the BBC, (3) on the BBC to
> run on another host system?
> 
> I would not be offended if the answer to some of those were "mu".

	The answer is no for all of the lettered questions.  Possibly
"mu" for all of the numbered.  The arch string only affects the arch
string reported by glibc etc on the running system.  There are also
precious few packages where we specify --build and --host, glibc being
the only big one I can think of (aside from nate's recent ccache
checkin).

	1 and 2 are no, to my estimation.  The whole purpose of these
flags is precisely what we attempt to do.  3 seems irrelevant to me.
If you want a program for your other system, compile it.  We're
internally consistent, and that's all that matters to me.  It's likely
that our binaries would run on other systems, but I really don't care.

> I'm assuming that this arch string does not affect the actual binary
> format of anything, but I wonder if it can confuse configure scripts
> or tools run from configure scripts.  If only I were able to take
> Nick's tutorial, I'm sure my confusion about these effects would be
> cleared up quickly.

	I'm delivering it this monday at 1pm, if you have a few
thousand dollars to cough up.  Also, a lot of these proposed changes
are the result of Daniel Jacobowitz schooling me with the rather more
(Continue reading)

Permalink | Reply | 0 comments |
headers
Seth David Schoen | 4 Aug 2003 03:08

bug#389: bbc-provided should use bbc-release file

Package: bbc-provided

I just added man page support to bbc-provided in
special/bbc-provided/files/bashrc.  The support here hard-codes the
BBC version to 2.1, but it should be available in /etc/bbc-release
(and we should use the information there).

However, in order to make this work with nightlies, we first need to
use Nate's mod_rewrite suggestion to make our Apache respond correctly
to requests for BBC versions which are nightlies.

--

-- 
Seth David Schoen <schoen <at> loyalty.org> | Very frankly, I am opposed to people
     http://www.loyalty.org/~schoen/   | being programmed by others.
     http://vitanuova.loyalty.org/     |     -- Fred Rogers (1928-2003),
                                       |        464 U.S. 417, 445 (1984)
Permalink | Reply | 1 comment |
headers
Seth David Schoen | 4 Aug 2003 09:13

bug#390: Generate man pages

Package: lnx-bbc

There needs to be a target which can generate the man pages for a
particular distribution so that they can be published on our web site
and accessible to people who type "man".  See the bbc-provided package
for where they need to go on our site.

--

-- 
Seth David Schoen <schoen <at> loyalty.org> | Very frankly, I am opposed to people
     http://www.loyalty.org/~schoen/   | being programmed by others.
     http://vitanuova.loyalty.org/     |     -- Fred Rogers (1928-2003),
                                       |        464 U.S. 417, 445 (1984)
Permalink | Reply | 0 comments |
headers
Karl Sackett | 8 Aug 2003 23:23
Favicon
Gravatar

bug#391: zlib: undefined references when building

Package: zlib
Version: 1.1.4

I'm building the RELEASE branch on a workstation running Debian testing.
After the library is compiled I get these error messages:

i386-pc-linux-gnu-gcc -Os -I//tmp/build/staging/singularity/image//include
-L//tmp/build/staging/singularity/image//lib
-I//tmp/build/staging/singularity/image//lib/gcc-lib/i386-pc-linux-gnu/2.95.3/include
-I//tmp/build/lib/gcc-lib/i386-pc-linux-gnu/2.95.3/include
-L//tmp/build/staging/singularity/image//lib/gcc-lib/i386-pc-linux-gnu/2.95.3
-L//tmp/build/lib/gcc-lib/i386-pc-linux-gnu/2.95.3 -DHAVE_UNISTD_H -DUSE_MMAP -o example
example.o -L. -lz
//tmp/build/staging/singularity/image//lib/libc.so.6: undefined //reference to `_dl_lazy <at> GLIBC_2.1.1'
//tmp/build/staging/singularity/image//lib/libc.so.6: undefined //reference to `_dl_dst_substitute <at> GLIBC_2.1.1'
//tmp/build/staging/singularity/image//lib/libc.so.6: undefined //reference to `_dl_out_of_memory <at> GLIBC_2.2'

(...)

//tmp/build/staging/singularity/image//lib/libc.so.6: undefined //reference to `_dl_fpu_control <at> GLIBC_2.1'
//tmp/build/staging/singularity/image//lib/libc.so.6: undefined //reference to `_dl_global_scope_alloc <at> GLIBC_2.1'
collect2: ld returned 1 exit status
make[9]: *** [example] Error 1
make[9]: Leaving directory
`/home/krs/src/gar/lib/zlib/work/singularity.d/zlib-1.1.4'

--

-- 
Karl Sackett                     K4KRS                    krs <at> hiwaay.net

         "It's kind of fun to do the impossible." - Walt Disney
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nate Riffe | 8 Aug 2003 23:48
Favicon

bug#391: wrong build platform

391-done <at> bugs.lnx-bbc.org
Cc: 
Bcc: 
Subject: Re: [Lnx-bbc-bugs] bug#391: zlib: undefined references when building
Reply-To: 
In-Reply-To: <20030808212326.GC754395 <at> hiwaay.net>
X-pw: reindeer flotilla

Just now Karl Sackett made 15 LEDs in my apartment flash with this:
> I'm building the RELEASE branch on a workstation running Debian testing.

Use Debian 3.0 (a/k/a Debian stable, Debian woody) to build the 2.0
release, 2.1 release, and STABLE cvs tag.

--

-- 
--< ((\))< >----< inkblot <at> movealong.org >----< http://www.movealong.org/ >--
pub  1024D/05A058E0 2002-03-07 Nate Riffe (06-Mar-2002) <inkblot <at> movealong.org>
     Key fingerprint = 0DAC F5CB D182 3165 D757  C466 CD42 12A8 05A0 58E0
Permalink | Reply | 0 comments |
headers
LNX-BBC bug Tracking System | 8 Aug 2003 23:50

bug#391: marked as done (zlib: undefined references when building)

Your message dated Fri, 8 Aug 2003 16:48:35 -0500
with message-id <20030808214835.GA5698 <at> movealong.org>
and subject line wrong build platform
has caused the attached bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Nick Moffitt
(administrator, LNX-BBC bugs database)

--------------------------------------
Received: (at submit) by bugs.lnx-bbc.org; 8 Aug 2003 21:23:29 +0000
>From krs <at> ant.hiwaay.net Fri Aug 08 14:23:29 2003
Received: from ant.hiwaay.net ([216.180.54.10] helo=mail.hiwaay.net)
	by gargoyle.lnx-bbc.org with esmtp (Exim 3.35 #1 (Debian))
	id 19lEht-00035d-00
	for <submit <at> bugs.lnx-bbc.org>; Fri, 08 Aug 2003 14:23:29 -0700
Received: from ant.hiwaay.net (ant.hiwaay.net [216.180.54.10])
	by mail.hiwaay.net (8.12.9/8.12.9) with ESMTP id h78LNRwA868380
	for <submit <at> bugs.lnx-bbc.org>; Fri, 8 Aug 2003 16:23:27 -0500 (CDT)
Received: (from krs <at> localhost)
	by ant.hiwaay.net (8.12.9/8.12.9/DefSubmit) id h78LNRAn877907
	for submit <at> bugs.lnx-bbc.org; Fri, 8 Aug 2003 16:23:27 -0500 (CDT)
Date: Fri, 8 Aug 2003 16:23:26 -0500
(Continue reading)

Permalink | Reply | 0 comments |

Gmane