Debian Developers - How should stalin be handled on slower architectures?

Author

How should stalin be handled on slower architectures?

Rob Browning

2004-09-23, 9:12 am

Summary: An RC bug has been filed claiming that stalin's source is
"too big" and that it shouldn't be built for m68k (and I'd presume
arm), though it has been built on both in the past. So I'd like to
figure out what action, if any, would be appropriate.

A bit back, a new version of stalin was uploaded which was intended
for testing. It has built for i386 and sparc, but hasn't built yet
for m68k or arm (though we have packages of the previous version for
both of those architectures). The arm build was attempted, but
failed, most likely because it wasn't given enough time; I asked about
extending the build time on arm, but never heard back.

Just recently Matthais filed an RC bug claiming that "the source is
too large" (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271836).

For those that don't know, stalin is very demanding on the build host.
It consists of one 22MB C file, so it does take a *very* long time to
build on older architectures. Accordingly, I try to be careful to not
upload new versions very frequently.

While I'm not very inclined to agree that the size of the source is a
release critical bug, especially since we've already been providing
packages for those architectures. I am willing to consider dropping
support for slower architectures if that's the "right thing to do".

Thoughts? Any relevant policy I might have overlooked?

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Palmer

2004-09-23, 9:12 am

On Wed, Sep 22, 2004 at 11:44:30PM -0500, Rob Browning wrote:
> For those that don't know, stalin is very demanding on the build host.
> It consists of one 22MB C file, so it does take a *very* long time to
> build on older architectures. Accordingly, I try to be careful to not
> upload new versions very frequently.

That's one honking great source file. I don't suppose that splitting it
into lots of little files would be a possibility? My guess is that the
source file is auto-generated in some way, but it seems like that would be
one way of reducing the demands somewhat (I imagine that GCC would chew
incredible amounts of memory trying to compile and optimize a source file of
that size). Perhaps even some sort of auto-split file might work -- one
function per file or something, and a big .h file with all of the function
prototypes #included at the top of each. Again, possibly not practical, but
I figure impractical suggestions are better than none.

> While I'm not very inclined to agree that the size of the source is a
> release critical bug,

Not as such, no. However, an inability to build on an architecture is a
FTBFS bug, which is typically RC. It appears, though, that it's more of an
autobuilder limitation than anything (finite RAM and run time, and a need to
process other packages sometime before the heat death of the universe) than
a true fail-to-build on an architecture. Could you perhaps build on
non-autobuilder machines for those slower arches and make new Debian
releases that way?

> especially since we've already been providing
> packages for those architectures. I am willing to consider dropping
> support for slower architectures if that's the "right thing to do".

Does the package do useful things on those slower arches once compiled?
(Practical performance-wise, mostly) If so, I don't think that removing
support for those architectures is a winner.

- Matt

Thomas Bushnell BSG

2004-09-23, 9:12 am

Rob Browning <rlb@defaultvalue.org> writes:

> For those that don't know, stalin is very demanding on the build host.
> It consists of one 22MB C file, so it does take a *very* long time to
> build on older architectures. Accordingly, I try to be careful to not
> upload new versions very frequently.

Why not just break it up into pieces and end the problem?

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Adam Majer

2004-09-23, 9:12 am

Rob Browning wrote:

>For those that don't know, stalin is very demanding on the build host.
>It consists of one 22MB C file, so it does take a *very* long time to
>build on older architectures. Accordingly, I try to be careful to not
>upload new versions very frequently.
>
>
[snip]

>Thoughts? Any relevant policy I might have overlooked?
>
>

My first comment would be: "For Pete's sake, a 22MB C file!"

The problem is that the source code is basically one humongous function,
at least at first glance. On my box, it took about a few minutes to
compile and over 320MB of RAM. Since there is no m68k machine with more
than 256MB, this will cause gcc to use swap, a lot, slowing things down
even further.

So, it is *possible* to build stalin on all arch, but it might not be
practical.

This raises some other questions. Do we need bloated software on arches
where it will not be used? For example, mysql-admin or mysqlcc[1]. Would
software like this be even used on m68k when mysql-client is available?
Or is the build process on old archs more informational (eg. portability
problems) than practical?

- Adam

[1] - picked my packages on purpose to avoid flames

--
Building your applications one byte at a time
http://www.galacticasoftware.com

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Steve Langasek

2004-09-23, 9:12 am

On Wed, Sep 22, 2004 at 11:44:30PM -0500, Rob Browning wrote:

> Summary: An RC bug has been filed claiming that stalin's source is
> "too big" and that it shouldn't be built for m68k (and I'd presume
> arm), though it has been built on both in the past. So I'd like to
> figure out what action, if any, would be appropriate.

The bug report isn't about whether the package *should* be built for
m68k and arm, it's about whether it *can* be built for m68k and arm.

> A bit back, a new version of stalin was uploaded which was intended
> for testing. It has built for i386 and sparc, but hasn't built yet
> for m68k or arm (though we have packages of the previous version for
> both of those architectures).

The packages for m68k were removed from unstable a while ago.

> The arm build was attempted, but failed, most likely because it wasn't
> given enough time; I asked about extending the build time on arm, but
> never heard back.

The last successful build on arm took < 3 hours; the most recent build
failure there spent 5 hours trying to compile the C file in question
without finishing it. There may be a difference in the relative power
of smackdown and netwinder that explains this, or there may be toolchain
differences that account for it. OTOH, this could also be a sign of a
regression in the stalin sources between 0.9 and 0.9+0.10alpha2.

> While I'm not very inclined to agree that the size of the source is a
> release critical bug, especially since we've already been providing
> packages for those architectures. I am willing to consider dropping
> support for slower architectures if that's the "right thing to do".

> Thoughts? Any relevant policy I might have overlooked?

If the current toolchain is less forgiving than the version last used to
build the package on arm, and it's no longer possible to build the
package using the available build environments, we have an RC bug
because we shouldn't ship binaries that we know we can't provide
critical updates for.

If the failure is caused by source changes in stalin itself that make
the package more resource-intensive to build, we again have a serious
bug (though only applicable to unstable) if the arm porters feel it's
not reasonable to accomodate the package's build requirements.

If you and the arm buildd maintainers can't come to an agreement that
lets stalin build again on this architecture, the out-of-date binaries
will need to be removed from the archive by an ftp-master.

FWIW, since the problematic source file is in fact generated by stalin,
and is exemplary of the kind of C code stalin generates in the course of
normal use, I'd question how useful this package is on architectures
that have a hard time building it.

--
Steve Langasek
postmodern programmer

Henning Makholm

2004-09-23, 9:12 am

Scripsit Adam Majer <adamm@galacticasoftware.com>

> My first comment would be: "For Pete's sake, a 22MB C file!"

> The problem is that the source code is basically one humongous function,
> at least at first glance.

Not really. The two longest function bodies seem to be about 20,000
no-comment lines in length, whereas the entire file has more than
400,000 non-comment lines.

Thus it ought to be possible to spilt the source into several batches
automatically. Its structure is fairly regular - a quick and dirty
job could probably be done with a day's PERL hacking.

On the other hand, it is likely that the 20,000 line functions are
what causes the majority of the thrashing. As far as I understand, gcc
will by default compile one function at a time, flushing the locally
used memory after each. Each of the long functions has a *lot* of
local variables, which is known to cause all sorts of trouble for
compilers written with very few local variables in mind.

On the third hand, perhaps splitting would allow one to select a
coarser optimization setting for the huge functions, while keeping -O2
for source files with functions that have a more manageable size.

--
Henning Makholm "Det er sympatisk du håner dig selv. Fuldt
berettiget. Men det gør dig ikke til en kristen."

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ingo Juergensmann

2004-09-23, 9:12 am

On Thu, Sep 23, 2004 at 12:26:37AM -0500, Adam Majer wrote:

> The problem is that the source code is basically one humongous function,
> at least at first glance. On my box, it took about a few minutes to
> compile and over 320MB of RAM. Since there is no m68k machine with more
> than 256MB, this will cause gcc to use swap, a lot, slowing things down
> even further.

Only 320 MB? Where's the problem then? I already built packages consuming
~600 MB during build (r-base) on a 64 MB RAM machine.
Of course it will need some time to build, but it's as well a matter of how
you setup your swap space and how the memory in that swap will be accessed.

When the compiler accesses the memory consecutively a single swap partition
might be enough. But most likely the compiler reads from swap in a more
randomly way, so having just one big and single swap partition on a slow
disk (I'll consider 3 MB/s nowadays a slow disk, but some m68k buildds would
be happy to have such fast disks) might be the wrong decision. Then a bunch
of smaller swap partitions on multiple disks (and maybe even multiple SCSI
hostadaptors) will be the better choice. When r-base was consuming 590 MB in
its docs generation with perl, arrakis was swapping like hell but it stayed
*very* responsive due to it's 5 swap partitions on 5 disks on 2 different
hostadaptors.

So, the conclusion is: only because it uses lots of swap space, it doesn't
need to be slow.

But again m68k has the advantage of having an army of buildds (usually), so
it doesn't matter if a single buildd is swapping like hell for a whole week,
whereas other archs will have more problems with those kind of problems.

> This raises some other questions. Do we need bloated software on arches
> where it will not be used? For example, mysql-admin or mysqlcc[1]. Would
> software like this be even used on m68k when mysql-client is available?
> Or is the build process on old archs more informational (eg. portability
> problems) than practical?

Oh well... you'll never know how crazy users can be... ;)

PS:
I'm just building stalin on spice, just for fun and to show it's doable and
no problem. (if there's no other FTBFS, that is)

--
Ciao... //
Ingo \X/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ingo Juergensmann

2004-09-23, 9:12 am

On Wed, Sep 22, 2004 at 10:59:11PM -0700, Steve Langasek wrote:

> The bug report isn't about whether the package *should* be built for
> m68k and arm, it's about whether it *can* be built for m68k and arm.

Why shouldn't it buildable? Just because it uses some little swap space and
outputs nothing to the build log, so it gets killed after reaching the
timeout? ;)

The first can be solved with throwing more swap space in, the latter with a
small task outputting a line of "I'm still compiling..." once in an hour or
so...

--
Ciao... //
Ingo \X/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

William Lee Irwin III

2004-09-23, 9:12 am

On Thu, Sep 23, 2004 at 12:26:37AM -0500, Adam Majer wrote:
> My first comment would be: "For Pete's sake, a 22MB C file!"
> The problem is that the source code is basically one humongous function,
> at least at first glance. On my box, it took about a few minutes to
> compile and over 320MB of RAM. Since there is no m68k machine with more
> than 256MB, this will cause gcc to use swap, a lot, slowing things down
> even further.
> So, it is *possible* to build stalin on all arch, but it might not be
> practical.
> This raises some other questions. Do we need bloated software on arches
> where it will not be used? For example, mysql-admin or mysqlcc[1]. Would
> software like this be even used on m68k when mysql-client is available?
> Or is the build process on old archs more informational (eg. portability
> problems) than practical?

BBN Butterflies were m68k boxen with > 256MB RAM.

-- wli

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Florian Weimer

2004-09-23, 9:12 am

* Thomas Bushnell:

> Rob Browning <rlb@defaultvalue.org> writes:
>
>
> Why not just break it up into pieces and end the problem?

This is not an option. Compilations of this size will be more common
once GCC supports inter-module analsysis.

Mandatory cross-compilation of Debian packages is the only long-term
answer to this set of problem because we won't magically get more
address space or MIPS for legacy and embedded architectures.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Cameron Patrick

2004-09-23, 9:12 am

Florian Weimer wrote:

> Mandatory cross-compilation of Debian packages is the only long-term
> answer to this set of problem because we won't magically get more
> address space or MIPS for legacy and embedded architectures.

A lot of packages don't support full cross-compilation. I suppose
using distcc or similar will help a bit and not need modification to
packages, though.

Are we at the point yet where emulating a MIPS or m68k on a cheap,
fast machine will go faster than the original hardware? Maybe the
next m68k or mips buildds might actually an i386...

Cameron.

Wouter Verhelst

2004-09-23, 9:12 am

On Thu, Sep 23, 2004 at 12:26:37AM -0500, Adam Majer wrote:
> Or is the build process on old archs more informational (eg. portability
> problems) than practical?

Both.

We let our users decide what is useful on any given architecture,
instead of trying to decide that for us. The problem with trying to
decide what a useful subset of software would be is that there will
always be a gray line, and that there will always be users who disagree.

So we don't.

Obviously, building everything everywhere also helps portability.

--
EARTH
smog | bricks
AIR -- mud -- FIRE
soda water | tequila
WATER
-- with thanks to fortune

Florian Weimer

2004-09-23, 9:12 am

* Cameron Patrick:

> Florian Weimer wrote:
>
>
> A lot of packages don't support full cross-compilation.

They have to be fixed once there is consensus that this is a desirable
goal.

> I suppose using distcc or similar will help a bit and not need
> modification to packages, though.

distcc doesn't help at all because it doesn't solve the problem of
huge files.

> Are we at the point yet where emulating a MIPS or m68k on a cheap,
> fast machine will go faster than the original hardware?

Current MIPS CPUs are faster than x86 for some workloads.

Efficient emulation has significant costs: somebody has to write the
emulator. Do you propose that Debian licenses a proprietary emulator
for its buildds? Writing an emulator (or optimizing an existing one)
is an atypical task because free software does hardly benefit from it.

> Maybe the next m68k or mips buildds might actually an i386...

cross-compilation is a way to achieve that. There's a main advantage
over emulation: fixing packages distributes the work load evenly among
package maintainers (especially once there's a fakeroot patch to
emulate a cross-compilation environment). Writing and maintaining an
emulator is a more centralized task.

We need cross-compilation for other reasons as well: currently, there
is too little redundancy among the trusted buildds for security
updates. One failed buildd delays security updates for the whole
distribution.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ingo Juergensmann

2004-09-23, 9:12 am

On Thu, Sep 23, 2004 at 01:42:36PM +0200, Florian Weimer wrote:

> We need cross-compilation for other reasons as well: currently, there
> is too little redundancy among the trusted buildds for security
> updates. One failed buildd delays security updates for the whole
> distribution.

I wouldn't say that this result in needs for crosscompilers, but in
increasing the number of machines available for such kind of builds.

--
Ciao... //
Ingo \X/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Cameron Patrick

2004-09-23, 9:12 am

Florian Weimer wrote:

>
> distcc doesn't help at all because it doesn't solve the problem of
> huge files.

It does if the distcc slaves are e.g. fast i386 cross-compilers
spitting out m68k or MIPS machine code. The build system doesn't know
what architecture the distcc machines are running, it's all abstracted
through the distcc network protocol.

Cameron.

Florian Weimer

2004-09-23, 9:12 am

* Ingo Juergensmann:

> On Thu, Sep 23, 2004 at 01:42:36PM +0200, Florian Weimer wrote:
>
>
> I wouldn't say that this result in needs for crosscompilers, but in
> increasing the number of machines available for such kind of builds.

The activity on these buildds is covered by the vendor-sec pseudo-NDA,
so they have to be restricted (maybe to a point that you build only
security updates on them). I consider this as a waste of resources.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Florian Weimer

2004-09-23, 9:12 am

* Cameron Patrick:

> Florian Weimer wrote:
>
>
> It does if the distcc slaves are e.g. fast i386 cross-compilers
> spitting out m68k or MIPS machine code. The build system doesn't know
> what architecture the distcc machines are running, it's all abstracted
> through the distcc network protocol.

Ah, this is indeed a clever idea. 8-) It's vastly superior to complete
emulation.

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ingo Juergensmann

2004-09-23, 9:12 am

On Thu, Sep 23, 2004 at 01:59:45PM +0200, Florian Weimer wrote:

> The activity on these buildds is covered by the vendor-sec pseudo-NDA,
> so they have to be restricted (maybe to a point that you build only
> security updates on them). I consider this as a waste of resources.

So what? Mips for example have had that many machines offers that this could
be easily done, but often those machines were rejected just because they had
r4ks instead of r5ks and therefor were labeled as "slow". *That's* a waste
of resources, IMHO...

As long as there's enough hardware, I see no need for crosscompilers except
for testing purposes (like new kernel images for m68k before the final build
runs natively, which is then uploaded).
Of course you'll need to ask actively for hardware donations especially for
older and exotic hardware, if you want to use it in some way or another.
Just sitting there and waiting silently until someone offers you some
hardware first, won't do the job.

--
Ciao... //
Ingo \X/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Gunnar Wolf

2004-09-23, 5:55 pm

Hi,

Cameron Patrick dijo [Thu, Sep 23, 2004 at 04:52:21PM +0800]:
> Are we at the point yet where emulating a MIPS or m68k on a cheap,
> fast machine will go faster than the original hardware? Maybe the
> next m68k or mips buildds might actually an i386...

Yes. For m68k, at least, and for many years. I recently got a Mac
Quadra 950, which is among the best m68k machines you can find - There
is a free emulator (in contrib, as it requires Apple ROMs) called
basilisk2, and it feels quite similar to the real machine. I used UAE
many years ago, and it also felt up to speed with the Amiga machines I
had worked with.

Yes, some people have pointed out an important problem with this: What
happens if we get a strange error for a specific package? How can we
be sure it is the package's fault and not the emulator's? Or the other
way around, what happens if something works correctly on an emulated
machine but not on the real one? That can lead to serious and annoying
debug time for a developer.

Greetings,

--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Gunnar Wolf

2004-09-23, 5:55 pm

Florian Weimer dijo [Thu, Sep 23, 2004 at 01:42:36PM +0200]:
> (...)
> Efficient emulation has significant costs: somebody has to write the
> emulator. Do you propose that Debian licenses a proprietary emulator
> for its buildds? Writing an emulator (or optimizing an existing one)
> is an atypical task because free software does hardly benefit from it.

But for some architectures we do already have the emulators
working. And they are quite popular and useful.

>
> cross-compilation is a way to achieve that. There's a main advantage
> over emulation: fixing packages distributes the work load evenly among
> package maintainers (especially once there's a fakeroot patch to
> emulate a cross-compilation environment). Writing and maintaining an
> emulator is a more centralized task.

On the other hand, I usually include -and encourage other people to
include- tests in my packages (i.e., 'make test' in a PERL module will
test it works as it should). If we were to switch to cross-compiling
environments, we would be unable to run the tests. Most packages would
FTBFS as they would require running a foreign binary, and the overall
quality of the archive would be decreased.

> We need cross-compilation for other reasons as well: currently, there
> is too little redundancy among the trusted buildds for security
> updates. One failed buildd delays security updates for the whole
> distribution.

On this point, I do agree... But I am still not convinced that
cross-compilation is the way to go.

Greetings,

--
Gunnar Wolf - gwolf@gwolf.org - (+52-55)1451-2244 / 5554-9450
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Weinehall

2004-09-23, 5:55 pm

On Thu, Sep 23, 2004 at 04:52:21PM +0800, Cameron Patrick wrote:
> Florian Weimer wrote:
>
>
> A lot of packages don't support full cross-compilation. I suppose
> using distcc or similar will help a bit and not need modification to
> packages, though.

Using scratchbox (www.scratchbox.org) most packages can be compiled
without worrying about the normal cross-compiling issues. And
scratchbox is available as debian-packages (in fact, scratchbox is
developed mainly for a Debian environment...)

At the moment, only ARM, x86 and PPC are supported (simply because of
the developers' focus), but since it's a GPL'd project, adding support
for other platforms is simply an issue of putting down the effort =)

Scratchbox performs most of the compilation using a cross-compiler,
but all things that require the real thing (things like binaries that run
on the target during configure-phase, etc.) are built using either
cpu-transparency (a real machine) or emulation (qemu).

[snip]

Regards: David Weinehall
--
/) David Weinehall <tao@acc.umu.se> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Ingo Juergensmann

2004-09-23, 5:55 pm

Nikita V. Youshchenko

2004-09-24, 7:49 am

> On Thu, Sep 23, 2004 at 04:52:21PM +0800, Cameron Patrick wrote:
>
> Using scratchbox (www.scratchbox.org) most packages can be compiled
> without worrying about the normal cross-compiling issues. And
> scratchbox is available as debian-packages (in fact, scratchbox is
> developed mainly for a Debian environment...)
>
> At the moment, only ARM, x86 and PPC are supported (simply because of
> the developers' focus), but since it's a GPL'd project, adding support
> for other platforms is simply an issue of putting down the effort =)
>
> Scratchbox performs most of the compilation using a cross-compiler,
> but all things that require the real thing (things like binaries that run
> on the target during configure-phase, etc.) are built using either
> cpu-transparency (a real machine) or emulation (qemu).

Btw, dpkg-cross is available to cross-compile debian packages. It supports
all debian linux targets (and gcc-3.3 debian source package may build
cross-compiler debs for all those; same about binutils patched by the patch
from #231707; pre-build cross-toolchain debs are at
http://zigzag.lvk.cs.msu.su/~nikita/debian).

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Rob Browning

2004-09-28, 5:57 pm

Steve Langasek <vorlon@debian.org> writes:

> The bug report isn't about whether the package *should* be built for
> m68k and arm, it's about whether it *can* be built for m68k and arm.

True, though since it has built in the past, and in the past the only
thing that had stopped it was a lack of build time, I presumed that
might be likely here as well. Though as Ingo's build determined,
there's someting else wrong with at least the m68k build.

>
> The packages for m68k were removed from unstable a while ago.

Ahh, right. I just meant that previous versions have built
successfully even though they were huge and took a while.

> without finishing it. There may be a difference in the relative power
> of smackdown and netwinder that explains this, or there may be toolchain
> differences that account for it. OTOH, this could also be a sign of a
> regression in the stalin sources between 0.9 and 0.9+0.10alpha2.

Previously, newer versions of gcc have made the compile take much
longer, even with the same stalin source, so I thought perhaps that
might be happening this time as well.

> If the current toolchain is less forgiving than the version last
> used to build the package on arm, and it's no longer possible to
> build the package using the available build environments, we have an
> RC bug because we shouldn't ship binaries that we know we can't
> provide critical updates for.

Certainly. I'll look in to the build problem with the current source,
but I can also see if the previous version will still build.

> If you and the arm buildd maintainers can't come to an agreement that
> lets stalin build again on this architecture, the out-of-date binaries
> will need to be removed from the archive by an ftp-master.

I haven't heard back from anyone associated with the arm buildds
AFAIK. Are the correct contact addresses listed somewhere? I tried
James and rmurray.

> FWIW, since the problematic source file is in fact generated by stalin,
> and is exemplary of the kind of C code stalin generates in the course of
> normal use,

I doubt that most code that people might want to compile with stalin
will be that big. The original source for stalin is a 1.1MB Scheme
file (stalin.sc). That's a quite a lot of Scheme code.

> I'd question how useful this package is on architectures that have a
> hard time building it.

That's basically the question I was asking. How do we decide when a
package isn't appropriate for a given architecture, if in fact, we
think it's appropriate to decide that for the users at all.

Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Rob Browning

2004-09-28, 5:57 pm

Henning Makholm <henning@makholm.net> writes:

> Not really. The two longest function bodies seem to be about 20,000
> no-comment lines in length, whereas the entire file has more than
> 400,000 non-comment lines.
>
> Thus it ought to be possible to spilt the source into several
> batches automatically.

Splitting the file might be possible, I'd have to ask upstream. I
don't think stalin's relying on cross-function optimizations to
guarantee Scheme semantics (for example, the guarantee of "no stack
growth for tail-recursive calls"), but I'd have to check to be sure.

One thing that does need fixing is that it should be emitting static
functions rather than global functions so that it won't overflow the
linker on the alpha.

--
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org