Re: [9fans] impressive

Re: [9fans] impressive

[erik quanstrom]

gcc 4 can be c99 compliant.

	gcc '--std=c99' $*

but that doesn't mean that they removed the extensions.

linux is dependent on inline assembly, for example.  (i'm not sure why they
think it necessiary.)  so a number of their extensions won't go away.  in fact,
other compilers, like tcc, feel compelled to replicate gnu extensions.

- erik

On Tue Apr 25 15:02:51 CDT 2006, cross@math.psu.edu wrote:
> On Tue, Apr 25, 2006 at 01:02:30PM +1000, Andy Newman wrote:
> > I like this quote from the glibc FAQ...
> >
> >     1.2. What compiler do I need to build GNU libc?
> >
> >     ...  A lot of extensions of GNU CC are used to increase portability ...
>
> I remember a year or two picking up a Linux rag at the train station on the
> way back from somewhere.  They were talking about gcc 4 or something in it
> and saying how they were hoping to do away with a lot of GNU extensions by
> stricter adherence to the language standards in the compiler itself; I guess
> that work got buried.  Then again, this was a cursory read on the Subway,
> and I'm slightly dyslexic, so maybe  read it the opposite way it was meant.
>
> 	- Dan C.
>

Re: [9fans] impressive

[geoff]

>From memory and a quick scan of gcc(1) since I don't have time to read
the entire manual ``page'' now, `gcc -ansi -pedantic' should compile
exactly 1990 ISO C and `gcc --std=c99 -pedantic' should compile
exactly 1999 ISO C. Using -pedantic-errors instead of -pedantic will
produce fatal errors rather than warnings for using extensions.

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 05:48:00PM -0700, geoff@collyer.net wrote:
> >From memory and a quick scan of gcc(1) since I don't have time to read
> the entire manual ``page'' now, `gcc -ansi -pedantic' should compile
> exactly 1990 ISO C and `gcc --std=c99 -pedantic' should compile
> exactly 1999 ISO C. Using -pedantic-errors instead of -pedantic will
> produce fatal errors rather than warnings for using extensions.

  gcc *can not* claim full ISO C99 compatibility for the variety of reasons,
  but the biggest one being -- glibc is not c99 complaint.

Thanks,
Roman.

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 07:26:56PM -0500, erik quanstrom wrote:
> gcc 4 can be c99 compliant.
>
> 	gcc '--std=c99' $*
>
> but that doesn't mean that they removed the extensions.
>
> linux is dependent on inline assembly, for example.  (i'm not sure why they
> think it necessiary.)  so a number of their extensions won't go away.  in fact,
> other compilers, like tcc, feel compelled to replicate gnu extensions.

  As a guy who started a port of Sun's compilers to Linux I must attest that
  glibc design is really bad when it comes to GNUisms. While porting I was
  treated to all sorts of junk there: incorrect C language constructs
  (_G_config.h: _G_iconv_t has a flexible array member as a non last member of
  the union), blatant GNUisms which break anything that doesn't explicitly claim
  to be __GNUC__ (dirent.h: take a look at readdir/readdir64 and ponder on
  what happens when #define readdir readdir64 kicks in but the actual
  structure remains to be dirent) and finally my favorite -- mismatched curly
  brackets in bits/mathcalls.h (around line 356) when a C++ compiler doesn't
  want to lie about being __USE_ISOC99.

  The worst of it is -- on a number of occasions glibc developers stated
  that they have no interest in supporting compilers other than gcc.

  That's precisely why everybody nowdays has to implement gcc quircks and
  pretend to be one by __GNUC__ :-(

Thanks,
Roman.

Re: [9fans] impressive

[Taj Khattra]

>   The worst of it is -- on a number of occasions glibc developers stated
>   that they have no interest in supporting compilers other than gcc.

http://udrepper.livejournal.com/7326.html:
    The only OSes supported in the [glibc] tree are Linux and to some
extend Hurd.
    ...
    For my new projects the razor is even sharper. Only Linux is supported...

we should be eternally grateful :)

Re: [9fans] impressive

[David Leimbach]

On 4/25/06, Taj Khattra <taj.khattra@gmail.com> wrote:
> >   The worst of it is -- on a number of occasions glibc developers stated
> >   that they have no interest in supporting compilers other than gcc.
>
> http://udrepper.livejournal.com/7326.html:
>     The only OSes supported in the [glibc] tree are Linux and to some
> extend Hurd.
>     ...
>     For my new projects the razor is even sharper. Only Linux is supported...
>
> we should be eternally grateful :)
>

There are some debian BSD projects that seem to try to use glibc if I
recall correctly.

Re: [9fans] impressive

[Anthony Sorace]

On 4/26/06, David Leimbach <leimy2k@gmail.com> wrote:

> There are some debian BSD projects that seem to try to use glibc if I
> recall correctly.

there's a handful of projects trying to port the Debian bits to
various BSDs. they all face the same argument early on: port glibc or
use the existing system one? the project almost always forks at that
point; the larger population goes with the system libc.

thankfully, none of the bsd w/ glibc projects have gotten more than
fringe traction.

Re: [9fans] impressive

[Rian Hunter]

On Tue, 2006-04-25 at 19:15 -0700, Taj Khattra wrote:
> >   The worst of it is -- on a number of occasions glibc developers stated
> >   that they have no interest in supporting compilers other than gcc.
>
> http://udrepper.livejournal.com/7326.html:
>     The only OSes supported in the [glibc] tree are Linux and to some
> extend Hurd.
>     ...
>     For my new projects the razor is even sharper. Only Linux is supported...
>
> we should be eternally grateful :)

God knows where this nut gets his logic. Of course all bad logic is
contradictory, if people only ever supported "majority" systems Linux
would never exist. Actually let's scratch anything ever existing.

Rian

Re: [9fans] impressive

[Micah Stetson]

> http://udrepper.livejournal.com/7326.html:
>     The only OSes supported in the [glibc] tree are Linux and to some
> extend Hurd.
>     ...
>     For my new projects the razor is even sharper. Only Linux is supported...

The part I find funny is that he calls everybody who doesn't like
autoconf a "winer" (am I a winner, a whiner, or a wiener? there's a
critical letter missing here) because it makes portability "quite
easy" and then proceeds to rant about how maintaining portable code is
too heavy a load for his projects to bear.  So it's too hard, but only
winners think he's doing it wrong?

Micah

Re: [9fans] impressive

[Bruce Ellis]

which one do you think is growing faster - autoconf or gcc?
or is there some symbiosis?

have a glass of wine anyway.

brucee

On 4/27/06, Micah Stetson <micah@stetsonnet.org> wrote:
> > http://udrepper.livejournal.com/7326.html:
> >     The only OSes supported in the [glibc] tree are Linux and to some
> > extend Hurd.
> >     ...
> >     For my new projects the razor is even sharper. Only Linux is supported...
>
> The part I find funny is that he calls everybody who doesn't like
> autoconf a "winer" (am I a winner, a whiner, or a wiener? there's a
> critical letter missing here) because it makes portability "quite
> easy" and then proceeds to rant about how maintaining portable code is
> too heavy a load for his projects to bear.  So it's too hard, but only
> winners think he's doing it wrong?
>
> Micah
>

Re: [9fans] impressive

[Micah Stetson]

> which one do you think is growing faster - autoconf or gcc?
> or is there some symbiosis?

I don't know, but there's definitely a bug here:

% ./configure
...
checking whether build environment is sane... yes
...

Micah

Re: [9fans] impressive

[Harri Haataja]

On Wed, Apr 26, 2006 at 09:39:33AM -0700, Micah Stetson wrote:
> > http://udrepper.livejournal.com/7326.html:
> >     The only OSes supported in the [glibc] tree are Linux and to some
> > extend Hurd.
> >     ...
> >     For my new projects the razor is even sharper. Only Linux is supported...
> 
> The part I find funny is that he calls everybody who doesn't like
> autoconf a "winer" (am I a winner, a whiner, or a wiener? there's a
> critical letter missing here)

You could be a winer: http://winehq.org

-- 
: Bandwidth is no longer as expensive, so that's no excuse
: anymore.  
It's not a matter of bandwidth any more, it's a matter of manners.
                -- Robert A. Uhl and Dave Brown, on .sigs, in the Monastery

Re: [9fans] impressive

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]

Well, for all the crap that autoconf addes, it still couldn't tell what was
wrong when building glibc. I had to build a tiny program to check out what
was really happening...

On 5/8/06, Harri Haataja <harriha@mail.student.oulu.fi> wrote:
>
> On Wed, Apr 26, 2006 at 09:39:33AM -0700, Micah Stetson wrote:
> > > http://udrepper.livejournal.com/7326.html:
> > >     The only OSes supported in the [glibc] tree are Linux and to some
> > > extend Hurd.
> > >     ...
> > >     For my new projects the razor is even sharper. Only Linux is
> supported...
> >
> > The part I find funny is that he calls everybody who doesn't like
> > autoconf a "winer" (am I a winner, a whiner, or a wiener? there's a
> > critical letter missing here)
>
> You could be a winer: http://winehq.org
>
> --
> : Bandwidth is no longer as expensive, so that's no excuse
> : anymore.
> It's not a matter of bandwidth any more, it's a matter of manners.
>                 -- Robert A. Uhl and Dave Brown, on .sigs, in the
> Monastery
>



--
Nietzsche's first step is to accept what he knows. Atheism for him goes
without saying and is "contructive and
radical". Nietzsche's supreme vocation, so he says, is to provoke a kind of
crisis and a final decision about the
problem of atheism. The world continues on its course at random and there is
nothing final about it. Thus God
is useless, since He wants nothing in particular. If he wanted something --
and here we recognize the traditional
forumlation of the problem of evil -- He would have to assume responsiblity
for "a sum total of pain and inconsistency
which would debase the entire value of being born."
-- Albert Camus, L'Homme révolté

[-- Attachment #2: Type: text/html, Size: 2318 bytes --]

Re: [9fans] impressive

[Charles Forsyth]

> Well, for all the crap that autoconf addes, it still couldn't tell what was
> wrong when building glibc. I had to build a tiny program to check out what
> was really happening...

i am surprised that many people still think that `autoconf' is short for `autoconfigure'
when obviously it means `autoconformity': it ensures that your system
conforms to the one system on which the software will compile and run without fuss.
it does that by breaking in increasingly obscure ways until you agree to conform.
or else.

Re: [9fans] impressive

[Micah Stetson]

> i am surprised that many people still think that `autoconf' is short for
> `autoconfigure' when obviously it means `autoconformity': it ensures that

Boy I learn something new from this list all the time.  A few weeks
ago, I though autoconf had no legitimate purpose.  Now I know that
it's a GNU/Linux advocacy tool with the added benefit of making people
feel good about backwards-incompatible library API changes.

Thank you!

Micah

Re: [9fans] impressive

[LiteStar numnums]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

The problem was that autoconf didn't configure nor test conformity: it
passed along without warning that
I was missing some important thread crap that changed betwixt versions it
seems. So for the half
our conformity test/configuration, it still wouldn't actually tell me what
was really missing, which was
fun because it kept passing the thread test sections...

On 5/8/06, Charles Forsyth <forsyth@terzarima.net> wrote:
>
> > Well, for all the crap that autoconf addes, it still couldn't tell what
> was
> > wrong when building glibc. I had to build a tiny program to check out
> what
> > was really happening...
>
> i am surprised that many people still think that `autoconf' is short for
> `autoconfigure'
> when obviously it means `autoconformity': it ensures that your system
> conforms to the one system on which the software will compile and run
> without fuss.
> it does that by breaking in increasingly obscure ways until you agree to
> conform.
> or else.
>
>


--
Nietzsche's first step is to accept what he knows. Atheism for him goes
without saying and is "contructive and
radical". Nietzsche's supreme vocation, so he says, is to provoke a kind of
crisis and a final decision about the
problem of atheism. The world continues on its course at random and there is
nothing final about it. Thus God
is useless, since He wants nothing in particular. If he wanted something --
and here we recognize the traditional
forumlation of the problem of evil -- He would have to assume responsiblity
for "a sum total of pain and inconsistency
which would debase the entire value of being born."
-- Albert Camus, L'Homme révolté

[-- Attachment #2: Type: text/html, Size: 2000 bytes --]

Re: [9fans] impressive

[Jack Johnson]

On 5/8/06, LiteStar numnums <litestar@gmail.com> wrote:
> seems. So for the half
> our conformity test/configuration, it still wouldn't actually tell me what
> was really missing, which was
> fun because it kept passing the thread test sections...

So, it sounds like autoconf may function as intended but perhaps the
person who wrote the test needs some help?

Given that progress is likely to be evolutionary rather than
revolutionary, what kind of system or environment do you see that has
potential to wean people from autoconf with as minimal hassle as
possible?  If I'm engrossed in autoconf hell for whatever reason --
say I'm the Firefox build maintainer, for instance -- what does the
path out look like?

-Jack

Re: [9fans] impressive

[andrey mirtchovski]

> Given that progress is likely to be evolutionary rather than
> revolutionary, what kind of system or environment do you see that has
> potential to wean people from autoconf with as minimal hassle as
> possible?

several times in the past i have been in a situation where i have
booted an old plan9 cd with missing incorrect binaries. in those cases
i have always resorted to mounting the latest set off sources and
either compiling them or (more often) just running the binaries off
the Bell-Labs servers.

perhaps the future _could_ be just providing an interface to the
required build libraries to those who dislike downloading binaries :)

perhaps i'm naive, but i've been spoiled with p9 :)

Re: [9fans] impressive

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Having been swearing at autoconf (and the code it causes) for much of  
a week, I can vouch for the brain damage.
Consider that at best it returns a list of available features; some  
of them are inferred by running the compiler, others by testing the  
environment.  Try cross-compiling with that kind of mess.
So after running configure, I get to hand-edit the resulting file and  
*try* to catch all the places where autocrap checked if /dev/ 
something existed, because all those are guaranteed wrong (some OSes  
don't have a /dev/...).
And the code people write to work around what autoconf says is at  
least as evil.  Python's posixmodule.c goes at least 5 levels of  
ifdefs deep, with no hope of figuring out which bits are for which  
platform.  I'd rather just re-write the whole module.

Paul

On 8-May-06, at 2:10 PM, Jack Johnson wrote:

> On 5/8/06, LiteStar numnums <litestar@gmail.com> wrote:
>> seems. So for the half
>> our conformity test/configuration, it still wouldn't actually tell  
>> me what
>> was really missing, which was
>> fun because it kept passing the thread test sections...
>
> So, it sounds like autoconf may function as intended but perhaps the
> person who wrote the test needs some help?
>
> Given that progress is likely to be evolutionary rather than
> revolutionary, what kind of system or environment do you see that has
> potential to wean people from autoconf with as minimal hassle as
> possible?  If I'm engrossed in autoconf hell for whatever reason --
> say I'm the Firefox build maintainer, for instance -- what does the
> path out look like?
>
> -Jack

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEX7WbpJeHo/Fbu1wRAh9kAJ9CkTOBzkFloLezuO80YFLxD9O3FwCdGtT2
dozIyAO7PIqrLkKeuwp0Ciw=
=Q9wi
-----END PGP SIGNATURE-----

Re: [9fans] impressive

[Francisco J Ballesteros]

When I had to work with autoconf'd packages, I found that they worked
(most times) for platforms already considered by the package maintainers.
Auto* was a big obstacle otherwise. In general, I ended up removing most of
the #ifdef code once I found which symbols were in place for the platform I
had to cope with.

When having to deal with several platforms, I applied the same technique to
lead to different .c files for the different platforms. This worked well for me.

On 5/8/06, Jack Johnson <knapjack@gmail.com> wrote:
> On 5/8/06, LiteStar numnums <litestar@gmail.com> wrote:
> > seems. So for the half
> > our conformity test/configuration, it still wouldn't actually tell me what
> > was really missing, which was
> > fun because it kept passing the thread test sections...
>
> So, it sounds like autoconf may function as intended but perhaps the
> person who wrote the test needs some help?
>
> Given that progress is likely to be evolutionary rather than
> revolutionary, what kind of system or environment do you see that has
> potential to wean people from autoconf with as minimal hassle as
> possible?  If I'm engrossed in autoconf hell for whatever reason --
> say I'm the Firefox build maintainer, for instance -- what does the
> path out look like?
>
> -Jack
>
>

Re: [9fans] impressive

[Dave Eckhardt]

The "old way" was to create an explicit portability layer,
with the application running on top of that layer and
one version of the layer for each platform.  So each
application would need one expert to maintain the SunOS
blob, one to maintain the HP-UX blob, etc.

The autoconf approach (following perl's pioneering
configuration infrastructure) was based on the observation
that the 1995 version of the SunOS blob and the 1995
version of the Irix blob looked somewhat like each other,
especially in the sense that if you looked at the 1998
version of each the underlying platforms had added many
of the same features.  Also, if you looked at the SunOS
blob for one application and the SunOS blob for another
application, they would of course share many similarities.

So the theory was to ignore platforms and start testing
for *features*, and the hope was that once a *feature*
had been coded for platforms would add the feature over
time and all software using autoconf would automatically
start using the feature.  Great!

But there are problems:

1. The language chosen for the configuration infrastructure,
sh, is an issue because it is REALLY hard to debug
5,000-line shell scripts which were generated by sh and
m4.  In the old days if you tried to build a package on
a too-new version of Solaris you might run into trouble
with the Solaris blob and need to contact the Solaris
expert who maintained it.  But *nobody* is an expert at
debugging 5,000-line machine-generated sh scripts, so
you just lose.

2. Feature-detection code ages very fast.  If the foo()
function used to be provided in -lmumble but suddenly is
moved -lfrobotz, or if /etc/foo.cfg is moved to
/var/etc/sbin/foo.cfg, then the test code for the foo
feature (cleverly written in m4 and turned into 237 lines
of unreadable sh) is broken.  Maybe you can figure out
how to fix it for your system, but the bad news is that
you need to fix it the same way for multiple applications
as you try to build them.

3. The interface between applications and the auto*
infrastructure changes pretty rapidly.  So if version 3
of your application is designed to work with version 47
of auto* and version 49 of auto* has better foo-detection
code, that doesn't help you at all because if you ask
version 49 of auto* to rebuild the 5,000-line shell script
to configure the application you'll find yourself debugging
amusing m4/sh errors (e.g., AC_META_FIZZBANG has been
replaced by AC_HYPER_FIZZBANG which has 7 more args
and uses a different quoting style).

The end result is that an autoconf-maintained package
will build pretty much on exactly the (platform, version)
tuples that one of the package maintainers built it on
as part of the release process, and likely not anywhere
else.

This is uncannily like the bad old days.  Furthermore,
when something is broken you're not trying to fix C code
in the application's Solaris blob, but trying to debug a
broken 5,000-line machine-generated sh script.  Sometimes
some of the application-supplied feature tests depend on
gawk as opposed to any other dialect of awk, so despite
the huge tracts of portability infrastructure actually
all of the (platform, version) tuples which work are some
flavor of Linux.  Resistance is futile!  You will be
assimilated!

Dave Eckhardt

Re: [9fans] impressive

[geoff]

5,000 lines is actually a rather small configure script.  These are
the configure scripts I have lying around (just on Plan 9, I haven't
even looked at my Mac or OpenBSD firewall) that exceed 5,000 lines:

   5520 /n/other/scr/src/gs/hpijs-1.5/configure
   5621 /sys/src/libdb/dist/configure
   5962 /sys/src/cmd/uucp.taylor/configure
   5962 /n/other/frommac/src/cmd/uucp/configure
   6722 /sys/src/cmd/links/configure
   6722 /n/other/scr/links/links.native/configure
   6722 /n/other/scr/links/links.varfont/configure
   7352 /n/other/scr/src/gs/jbig2dec/configure
   7751 /usr/geoff/src/cmd/unix/rc.byron/configure
   8000 /n/other/frommac/desk/gilmore/udftools-1.0.0b2/configure
   8250 /n/other/frommac/desk/src/flex/flex-2.5.31/configure
   9756 /n/other/scr/src/gs/configure
  11460 /n/other/frommac/desk/src/raid.evms/configure
  12676 /usr/geoff/src/cmd/grip/grip/configure
  13698 /n/other/scr/src/mp3enc.lame/configure
  16489 /usr/geoff/src/cmd/imagemagick/ltdl/configure
  16489 /n/other/dist/image.magick/im/ltdl/configure
  23719 /usr/geoff/src/cmd/imagemagick/configure
  23851 /n/other/frommac/src/cmd/bochs/configure
  25527 /n/other/dist/image.magick/im/configure
  25877 /n/other/scr/src/index/swishe/swish-e-2.4.2/configure

Trying to debug a machine-generated 25,000-line script is really fun.

Re: [9fans] impressive

[Lluís Batlle]

[-- Attachment #1: Type: text/plain, Size: 1769 bytes --]

It helps a bit the fact that the 'configure' script usually hasn't any sh
function definition; they're simply lots of instructions written and run in
order. So, if a program stops at one point, whenever you find the point, you
know (easier than with code with function) which code lines were run and
when.

2006/5/10, geoff@collyer.net <geoff@collyer.net>:
>
> 5,000 lines is actually a rather small configure script.  These are
> the configure scripts I have lying around (just on Plan 9, I haven't
> even looked at my Mac or OpenBSD firewall) that exceed 5,000 lines:
>
>    5520 /n/other/scr/src/gs/hpijs-1.5/configure
>    5621 /sys/src/libdb/dist/configure
>    5962 /sys/src/cmd/uucp.taylor/configure
>    5962 /n/other/frommac/src/cmd/uucp/configure
>    6722 /sys/src/cmd/links/configure
>    6722 /n/other/scr/links/links.native/configure
>    6722 /n/other/scr/links/links.varfont/configure
>    7352 /n/other/scr/src/gs/jbig2dec/configure
>    7751 /usr/geoff/src/cmd/unix/rc.byron/configure
>    8000 /n/other/frommac/desk/gilmore/udftools-1.0.0b2/configure
>    8250 /n/other/frommac/desk/src/flex/flex-2.5.31/configure
>    9756 /n/other/scr/src/gs/configure
>   11460 /n/other/frommac/desk/src/raid.evms/configure
>   12676 /usr/geoff/src/cmd/grip/grip/configure
>   13698 /n/other/scr/src/mp3enc.lame/configure
>   16489 /usr/geoff/src/cmd/imagemagick/ltdl/configure
>   16489 /n/other/dist/image.magick/im/ltdl/configure
>   23719 /usr/geoff/src/cmd/imagemagick/configure
>   23851 /n/other/frommac/src/cmd/bochs/configure
>   25527 /n/other/dist/image.magick/im/configure
>   25877 /n/other/scr/src/index/swishe/swish-e-2.4.2/configure
>
> Trying to debug a machine-generated 25,000-line script is really fun.
>
>

[-- Attachment #2: Type: text/html, Size: 2276 bytes --]

Re: [9fans] impressive

[geoff]

> what does the path out look like?

Writing portable code?  When autoconf was created, there was some
incompatibility in system call and library interfaces amongst (l)unix
systems.  Since ANSI/ISO C and POSIX, much of what autoconf was
originally intended to paper over is now standardised on (l)unix
systems, which is all that autoconf is intended to cover, I believe.

There are still fringe functions that only some systems have, and
autoconf now attempts to probe the outer limits of weirdness, but I
suspect that few programs *need* to use the fringe.  And where
necessary, one can provide alternate implementations of some
higher-level abstraction in different .c or .h files.

Re: [9fans] impressive

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Part of the problem is that autoconf also tries, weakly, to deal with  
cross-compilation.  It simultaneously gets blamed for the crap make  
systems that surround most larger systems - recursive make  
invocations that simply don't have enough of the tree to build non- 
trivial systems well.  Put those two elements together and you get a  
real mess.


On 8-May-06, at 4:31 PM, geoff@collyer.net wrote:

>> what does the path out look like?
>
> Writing portable code?  When autoconf was created, there was some
> incompatibility in system call and library interfaces amongst (l)unix
> systems.  Since ANSI/ISO C and POSIX, much of what autoconf was
> originally intended to paper over is now standardised on (l)unix
> systems, which is all that autoconf is intended to cover, I believe.
>
> There are still fringe functions that only some systems have, and
> autoconf now attempts to probe the outer limits of weirdness, but I
> suspect that few programs *need* to use the fringe.  And where
> necessary, one can provide alternate implementations of some
> higher-level abstraction in different .c or .h files.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEX+3ipJeHo/Fbu1wRAugmAJ9zYNPlXC7fvmvHD7AUkKeqLkUfogCfb98j
mJzIM9ErhSXhjYpqTBCs6Es=
=5887
-----END PGP SIGNATURE-----

Re: [9fans] impressive

[quanstro]

cross compile with gcc? you MUST be mad! ;-)

recursive make considered harmful.  yadda yadda yadda.  i've never seen
a reasonable solution to this problem?  while you could build a full dependency
graph with make or mk, it seems more trouble than it's worth.

i build a system like this for gnu make a year ago.  it was fragile and way too much work
to maintain.

- erik

On Mon May  8 20:19:44 CDT 2006, plalonde@telus.net wrote:
> 
> Part of the problem is that autoconf also tries, weakly, to deal with  
> cross-compilation.  It simultaneously gets blamed for the crap make  
> systems that surround most larger systems - recursive make  
> invocations that simply don't have enough of the tree to build non- 
> trivial systems well.  Put those two elements together and you get a  
> real mess.

Re: [9fans] impressive

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I just did it over the last two weeks.  Cross compiles 2.5 platfroms  
(SPUs are strange), with tests and debug targets.  Not too bad if you  
are willing to let *one* person hold the per-directory included- 
makefiles in order.  It makes a huge difference (both things, the  
full dependency tree, and the one person thing).
But the code is a little rude - your world winds up with too many  
parameterized make variables: $($(TARGETOS)$(DIR)BUILDDIR).  And you  
have to use GNU make's target-local variables to remember that state.
It ain't pretty.

Is there a better solution?

Paul

On 8-May-06, at 6:39 PM, quanstro@quanstro.net wrote:

> cross compile with gcc? you MUST be mad! ;-)
>
> recursive make considered harmful.  yadda yadda yadda.  i've never  
> seen
> a reasonable solution to this problem?  while you could build a  
> full dependency
> graph with make or mk, it seems more trouble than it's worth.
>
> i build a system like this for gnu make a year ago.  it was fragile  
> and way too much work
> to maintain.
>
> - erik
>
> On Mon May  8 20:19:44 CDT 2006, plalonde@telus.net wrote:
>>
>> Part of the problem is that autoconf also tries, weakly, to deal with
>> cross-compilation.  It simultaneously gets blamed for the crap make
>> systems that surround most larger systems - recursive make
>> invocations that simply don't have enough of the tree to build non-
>> trivial systems well.  Put those two elements together and you get a
>> real mess.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEX/p+pJeHo/Fbu1wRAsD1AKDQYaUKb6/RUxx3jSy+nQNIan5U1wCfZFe6
liLHRvL/8/QjjkW8Hd8ZFU4=
=wVrJ
-----END PGP SIGNATURE-----

Re: [9fans] impressive

[quanstro]

been there.  done that.  the problem is that you end up wasting one person's time
with build-related issues.  not many people understand make very well.
and parameterizing make variables -- which i was attempting to allude to ---
does not help matters.  

when i was knee deep in this dreck, i don't remember gnu make having target-local
variables.  i had to do it through other subterfuge, including VPATH and friends.

- erik

> I just did it over the last two weeks.  Cross compiles 2.5 platfroms  
> (SPUs are strange), with tests and debug targets.  Not too bad if you  
> are willing to let *one* person hold the per-directory included- 
> makefiles in order.  It makes a huge difference (both things, the  
> full dependency tree, and the one person thing).
> But the code is a little rude - your world winds up with too many  
> parameterized make variables: $($(TARGETOS)$(DIR)BUILDDIR).  And you  
> have to use GNU make's target-local variables to remember that state.
> It ain't pretty.
> 
> Is there a better solution?
> 
> Paul
> 

Re: [9fans] impressive

[Paul Lalonde]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Agreed on using up a person's time.  It's depressing that it takes  
one of the more senior people on any software team to properly  
maintain a build.  The other option is to acknowledge it will belong  
to some junior and be broken most of the time.
Builds shouldn't be rocket science, but every project I've worked on,  
even the best, have had a hard time with the mechanics of building  
(all of them have involved some non-trivial number of platforms to  
support: games suck that way).

Paul

On 8-May-06, at 7:20 PM, quanstro@quanstro.net wrote:

> been there.  done that.  the problem is that you end up wasting one  
> person's time
> with build-related issues.  not many people understand make very well.
> and parameterizing make variables -- which i was attempting to  
> allude to ---
> does not help matters.
>
> when i was knee deep in this dreck, i don't remember gnu make  
> having target-local
> variables.  i had to do it through other subterfuge, including  
> VPATH and friends.
>
> - erik
>
>> I just did it over the last two weeks.  Cross compiles 2.5 platfroms
>> (SPUs are strange), with tests and debug targets.  Not too bad if you
>> are willing to let *one* person hold the per-directory included-
>> makefiles in order.  It makes a huge difference (both things, the
>> full dependency tree, and the one person thing).
>> But the code is a little rude - your world winds up with too many
>> parameterized make variables: $($(TARGETOS)$(DIR)BUILDDIR).  And you
>> have to use GNU make's target-local variables to remember that state.
>> It ain't pretty.
>>
>> Is there a better solution?
>>
>> Paul
>>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEYAXppJeHo/Fbu1wRAqfwAJsFJbFW9PfQQoNixqvc7c/ezqLO5QCffjMh
hQLRO4ywOGBX/zlkIM51heo=
=gblJ
-----END PGP SIGNATURE-----

Re: [9fans] impressive

[Bruce Ellis]

if you want to have fun (?) with autoconfusion try it on the
playstation 2 linux kit.  gee 128 bit registers, missing
instrs, weird set of libraries etc.

i only had to set up a boot option for inferno.

it was quicker to hack 0c (0l mainly) into e[cla].

next day inferno on PS2.  if i was autoconfused by dumb
scripts i'd still be in NJ.  and /dev/dct, /dev/gpu? i believe
is a more usefull than APIs.

brucee

On 5/9/06, Paul Lalonde <plalonde@telus.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Agreed on using up a person's time.  It's depressing that it takes
> one of the more senior people on any software team to properly
> maintain a build.  The other option is to acknowledge it will belong
> to some junior and be broken most of the time.
> Builds shouldn't be rocket science, but every project I've worked on,
> even the best, have had a hard time with the mechanics of building
> (all of them have involved some non-trivial number of platforms to
> support: games suck that way).
>
> Paul
>
> On 8-May-06, at 7:20 PM, quanstro@quanstro.net wrote:
>
> > been there.  done that.  the problem is that you end up wasting one
> > person's time
> > with build-related issues.  not many people understand make very well.
> > and parameterizing make variables -- which i was attempting to
> > allude to ---
> > does not help matters.
> >
> > when i was knee deep in this dreck, i don't remember gnu make
> > having target-local
> > variables.  i had to do it through other subterfuge, including
> > VPATH and friends.
> >
> > - erik
> >
> >> I just did it over the last two weeks.  Cross compiles 2.5 platfroms
> >> (SPUs are strange), with tests and debug targets.  Not too bad if you
> >> are willing to let *one* person hold the per-directory included-
> >> makefiles in order.  It makes a huge difference (both things, the
> >> full dependency tree, and the one person thing).
> >> But the code is a little rude - your world winds up with too many
> >> parameterized make variables: $($(TARGETOS)$(DIR)BUILDDIR).  And you
> >> have to use GNU make's target-local variables to remember that state.
> >> It ain't pretty.
> >>
> >> Is there a better solution?
> >>
> >> Paul
> >>
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (Darwin)
>
> iD8DBQFEYAXppJeHo/Fbu1wRAqfwAJsFJbFW9PfQQoNixqvc7c/ezqLO5QCffjMh
> hQLRO4ywOGBX/zlkIM51heo=
> =gblJ
> -----END PGP SIGNATURE-----
>

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 07:15:43PM -0700, Taj Khattra wrote:
> >   The worst of it is -- on a number of occasions glibc developers stated
> >   that they have no interest in supporting compilers other than gcc.
>
> http://udrepper.livejournal.com/7326.html:
>     The only OSes supported in the [glibc] tree are Linux and to some
> extend Hurd.
>     ...
>     For my new projects the razor is even sharper. Only Linux is supported...
>
> we should be eternally grateful :)

  What is fascinating is a kind of rhetoric he uses. Even though
  his intent seems to be just the opposite one he comes across very
  much like being a part of a "violent minority" of a particular
  sort. Although, his mental condition, which manifests itself a bit
  in his writing, could help explain why it takes 31 lines of code
  to just declare a couple of function in glibc.

  Which makes me wonder -- with glibc and gcc descending into this
  political madness doesn't it actually kill the FSF/GNU movement ?

Thanks,
Roman.

P.S. I've kind of come to terms with the fact that working for
Sun and porting Sun's compilers to Linux makes me a "violent minority"
but I'm not sure whether it also makes me "pure evil" ;-)

Re: [9fans] impressive

[David Leimbach]

The main reason that intel and other C compilers implement gcc
extensions is because there is a lot of software that relies on them,
like the linux kernel for instance.



On 4/25/06, erik quanstrom <quanstro@quanstro.net> wrote:
> gcc 4 can be c99 compliant.
>
>         gcc '--std=c99' $*
>
> but that doesn't mean that they removed the extensions.
>
> linux is dependent on inline assembly, for example.  (i'm not sure why they
> think it necessiary.)  so a number of their extensions won't go away.  in fact,
> other compilers, like tcc, feel compelled to replicate gnu extensions.
>
> - erik
>
> On Tue Apr 25 15:02:51 CDT 2006, cross@math.psu.edu wrote:
> > On Tue, Apr 25, 2006 at 01:02:30PM +1000, Andy Newman wrote:
> > > I like this quote from the glibc FAQ...
> > >
> > >     1.2. What compiler do I need to build GNU libc?
> > >
> > >     ...  A lot of extensions of GNU CC are used to increase portability ...
> >
> > I remember a year or two picking up a Linux rag at the train station on the
> > way back from somewhere.  They were talking about gcc 4 or something in it
> > and saying how they were hoping to do away with a lot of GNU extensions by
> > stricter adherence to the language standards in the compiler itself; I guess
> > that work got buried.  Then again, this was a cursory read on the Subway,
> > and I'm slightly dyslexic, so maybe  read it the opposite way it was meant.
> >
> >       - Dan C.
> >
>

Re: [9fans] impressive

[Ronald G Minnich]

David Leimbach wrote:
> The main reason that intel and other C compilers implement gcc
> extensions is because there is a lot of software that relies on them,
> like the linux kernel for instance.

Yes, the standard question asked here when a company comes in with a
whiz-bang C compiler is 'can you build a bootable the linux kernel'. The
initial answer is always "no". It in the usual case remains "no". For
those companies that care (there are not many -- in fact there is only
one I can think of) it takes several years before the answer is "yes".

It's surprising how hard it is to write a "modern C compiler", as an
infrequent contributor to this list once described gcc.

That's life.

ron

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 10:53:35PM -0600, Ronald G Minnich wrote:
> David Leimbach wrote:
> >The main reason that intel and other C compilers implement gcc
> >extensions is because there is a lot of software that relies on them,
> >like the linux kernel for instance.
>
> Yes, the standard question asked here when a company comes in with a
> whiz-bang C compiler is 'can you build a bootable the linux kernel'. The
> initial answer is always "no". It in the usual case remains "no". For
> those companies that care (there are not many -- in fact there is only
> one I can think of)

  We (myself included) are trying to make it two ;-)

  <shameless plug>
  http://developers.sun.com/sunstudio/linux
  </shameless plug>

> it takes several years before the answer is "yes".

  The real problem is that its not just gcc compatibility, but rather
  gccX.Y compatibility. These guys are wild when it come to things like
  __asm__ specificators and such. In fact, Intel's dude I met at SC05
  was really proud that their compiler is more compatible with gcc
  than gcc itself. After all, icc has a gcc ABI switch ;-)

Thanks,
Roman.

Re: [9fans] impressive

[erik quanstrom]

i think your problems miss the point.  an explicit portability layer
is another name for a virtual os interface.  breaking things
up on a call-by-call basis creates calls^2 virtual os interfacen. 
good luck in testing.

of course the simple virtual interface is usually too simple to express
what the autoconf guys are really after, so they add a level of indirection.

the ironic bit about autoconf is that the vast majority of autoconf garbage
is dedicated to features that don't make any difference.  using the
lowest-common denomitor call would work just as well. (and why
not, you have to code this case anyway.)

it /is/ possible to make stuff portable across many different posixish
systems with very little code.  p9p really does a nice job.  there's some
glue, but that's mostly for the thread library and some networking goo.
most projects don't need to get that friendly with the hardware.

- erik

On Tue May  9 16:57:15 CDT 2006, davide+p9@cs.cmu.edu wrote:
> The "old way" was to create an explicit portability layer,
> with the application running on top of that layer and
> one version of the layer for each platform.  So each
> application would need one expert to maintain the SunOS
> blob, one to maintain the HP-UX blob, etc.
> 
> The autoconf approach (following perl's pioneering
> configuration infrastructure) was based on the observation
> that the 1995 version of the SunOS blob and the 1995
> version of the Irix blob looked somewhat like each other,
> especially in the sense that if you looked at the 1998
> version of each the underlying platforms had added many
> of the same features.  Also, if you looked at the SunOS
> blob for one application and the SunOS blob for another
> application, they would of course share many similarities.
> 
> So the theory was to ignore platforms and start testing
> for *features*, and the hope was that once a *feature*
> had been coded for platforms would add the feature over
> time and all software using autoconf would automatically
> start using the feature.  Great!

Re: [9fans] impressive

[Lyndon Nerenberg]

> i think your problems miss the point.  an explicit portability layer
> is another name for a virtual os interface.  breaking things
> up on a call-by-call basis creates calls^2 virtual os interfacen.
> good luck in testing.

And in the case of things like the APR, it forces you to learn an  
entirely new set of interfaces.

> the ironic bit about autoconf is that the vast majority of autoconf  
> garbage
> is dedicated to features that don't make any difference.  using the
> lowest-common denomitor call would work just as well. (and why
> not, you have to code this case anyway.)

A case in point is some web-related stuff I'm dealing with at work.   
I'll use libxml2 as an example.  A grep for HAVE_ at the top level of  
that source tree turns up:

HAVE_ANSIDECL_H
HAVE_ARPA_INET_H
HAVE_ARPA_NAMESER_H
HAVE_BEOS_THREADS
HAVE_COMPILER_TLS
HAVE_CTYPE_H
HAVE_DIRENT_H
HAVE_DLFCN_H
HAVE_ERRNO_H
HAVE_FCNTL_H
HAVE_FINITE
HAVE_FLOAT_H
HAVE_FPRINTF
HAVE_FSCANF
HAVE_FTIME
HAVE_GETADDRINFO
HAVE_GETTIMEOFDAY
HAVE_INTTYPES_H
HAVE_ISINF
HAVE_ISNAN
HAVE_LIBHISTORY
HAVE_LIBM
HAVE_LIBPTHREAD
HAVE_LIBREADLINE
HAVE_LIBZ
HAVE_LIMITS_H
HAVE_LOCALTIME
HAVE_MALLOC_H
HAVE_MATH_H
HAVE_MEMORY_H
HAVE_NETDB_H
HAVE_NETINET_IN_H
HAVE_PRINTF
HAVE_PTHREAD_H
HAVE_RESOLV_H
HAVE_SCANF
HAVE_SIGNAL
HAVE_SIGNAL_H
HAVE_SNPRINTF
HAVE_SPRINTF
HAVE_SSCANF
HAVE_STAT
HAVE_STDARG_H
HAVE_STDINT_H
HAVE_STDLIB_H
HAVE_STRDUP
HAVE_STRERROR
HAVE_STRFTIME
HAVE_STRINGS_H
HAVE_STRING_H
HAVE_STRNDUP
HAVE_SYS_MMAN_H
HAVE_SYS_SELECT_H
HAVE_SYS_SOCKET_H
HAVE_SYS_STAT_H
HAVE_SYS_TIMEB_H
HAVE_SYS_TIME_H
HAVE_SYS_TYPES_H
HAVE_TIME_H
HAVE_UNISTD_H
HAVE_VFPRINTF
HAVE_VFSCANF
HAVE_VPRINTF
HAVE_VSCANF
HAVE_VSNPRINTF
HAVE_VSPRINTF
HAVE_VSSCANF
HAVE_WIN32_THREADS
HAVE_ZLIB_H

If you weed out the bits that are already in Posix, you're left with  
a few legitimate feature tests (libz, libreadline, getaddrinfo), a  
test for the underlying threads implementation, workarounds for some  
obsolete variants of time handling (all of which can be accommodated  
by Posix), and some fancy printf variants, which the library has to  
provide compatibility routines for anyway.  And why the configure  
script cares about what version of FORTRAN 77 compiler I have simply  
escapes me.

It's endemic.  The fact that it's not malicious is even worse.  The  
people coding this stuff just don't know any better: they learn from  
what they see already deployed.  Critical thinking doesn't exist any  
more :-(

Another case in point ... this afternoon one of our product architects 
(!) informed us we needed to install a wiki on the production web  
blades. Why?  Because they needed to serve up some 'nicely formatted'  
static web pages to a couple of customers, and all they knew how to  
generate was in a wiki syntax format.  They didn't know how to turn  
that into pretty HTML, so this was the solution.  They were stunned  
when we proposed a simpler alternative.  (Call the documentation folks.)

--lyndon

Re: [9fans] impressive

[David Arnold]

-->"Lyndon" == Lyndon Nerenberg <lyndon@orthanc.ca> writes:

  Lyndon> If you weed out the bits that are already in Posix

one problem with a lot of code is that it's also "portable" to Windows.
using a manually-created config.h, and AC_REPLACE_FUNCS, the source
itself can maintain some internal consistency, if not total cleanliness.

  Lyndon> And why the configure script cares about what version of
  Lyndon> FORTRAN 77 compiler I have simply escapes me.

likely because it uses libtool, which automatically checks for FORTRAN
and C++ compilers, linkers, support for PIC, etc, regardless of whether
they're actually needed :-(

the benefit of libtool is that it centralises the magic required to
produce a shared library across various operating systems, compilers and
linkers.  it's a tradeoff most people are willing to make.




d

Re: [9fans] impressive

[Lyndon Nerenberg]

On May 9, 2006, at 8:35 PM, David Arnold wrote:

> the benefit of libtool is that it centralises the magic required to
> produce a shared library across various operating systems,  
> compilers and
> linkers.  it's a tradeoff most people are willing to make.

And that's the other half of the problem I've been working on:  
getting the code to build with static linkage.  It's the only way  
around linux shared library hell.

Re: [9fans] impressive

[erik quanstrom]

evolution guarantees change.  it doesn't guarantee /good/ change.
in software, i perfer intelligent design the dodo bird.

- erik

On Mon May  8 16:11:22 CDT 2006, knapjack@gmail.com wrote:
> On 5/8/06, LiteStar numnums <litestar@gmail.com> wrote:
> > seems. So for the half
> > our conformity test/configuration, it still wouldn't actually tell me what
> > was really missing, which was
> > fun because it kept passing the thread test sections...
> 
> So, it sounds like autoconf may function as intended but perhaps the
> person who wrote the test needs some help?
> 
> Given that progress is likely to be evolutionary rather than
> revolutionary, what kind of system or environment do you see that has
> potential to wean people from autoconf with as minimal hassle as
> possible?  If I'm engrossed in autoconf hell for whatever reason --
> say I'm the Firefox build maintainer, for instance -- what does the
> path out look like?
> 
> -Jack
> 

Re: [9fans] impressive

[erik quanstrom]

a new accusation leveled against me.  i'll have to add it to the list.

- erik

On Wed Apr 26 21:08:27 CDT 2006, knapjack@gmail.com wrote:
> On 4/26/06, erik quanstrom <quanstro@quanstro.net> wrote:
> > 100 Pure Evil™. ;-)
> 
> Now *that* is a marketing slogan!
> 
> -Jack

Re: [9fans] impressive

[erik quanstrom]

uh, i dunno.  stallman?

http://www.stallman.org/#long-term

- erik

On Wed Apr 26 10:29:39 CDT 2006, rian@MIT.EDU wrote:
>
> God knows where this nut gets his logic. Of course all bad logic is
> contradictory, if people only ever supported "majority" systems Linux
> would never exist. Actually let's scratch anything ever existing.
>
> Rian
>

Re: [9fans] impressive

[erik quanstrom]

[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]

unfortunately, this does makes sense.

while the code for autoconf has ballooned, it's support for non linux
systems has decreased.  i believe the folk who maintain it envision it
as a way to support a vast matrix of packages, each trying to use the
very most bleeding edge features of the others on linux.

this is often gratitous, and feeds on itself.  but there aren't many
services (e.g. 9660fs) in linux -- everything's a .so.

i've attached a dependency graph of mplayer on gentoo.  it's 160 lines.

- erik

On Wed Apr 26 11:40:44 CDT 2006, micah@stetsonnet.org wrote:
> > http://udrepper.livejournal.com/7326.html:
> >     The only OSes supported in the [glibc] tree are Linux and to some
> > extend Hurd.
> >     ...
> >     For my new projects the razor is even sharper. Only Linux is supported...
>
> The part I find funny is that he calls everybody who doesn't like
> autoconf a "winer" (am I a winner, a whiner, or a wiener? there's a
> critical letter missing here) because it makes portability "quite
> easy" and then proceeds to rant about how maintaining portable code is
> too heavy a load for his projects to bear.  So it's too hard, but only
> winners think he's doing it wrong?
>
> Micah

[-- Attachment #2: mplayer.dep --]
[-- Type: text/plain, Size: 8512 bytes --]

media-video/mplayer-1.0.20060415:
`-- media-video/mplayer-1.0.20060415
 `-- media-libs/xvid-1.0.3 [ xvid ]
  `-- dev-lang/nasm-0.98.39-r1 [ x86 ]
   `-- dev-lang/perl-5.8.7-r3 [ !build ]
    `-- sys-devel/libperl-5.8.7
     `-- sys-libs/db-4.2.52_p2-r1 [ berkdb ]
      `-- dev-lang/tcl-8.4.9 [ tcltk ]
       `-- sys-libs/glibc-2.3.5-r3 (virtual/libc)
        `-- sys-devel/gettext-0.14.4 [ nls ]
         `-- sys-devel/patch-2.5.9 [ !bootstrap ]
         `-- sys-apps/shadow-4.0.14-r1 [ !bootstrap userland_GNU ]
          `-- sys-libs/cracklib-2.8.5-r1
          `-- sys-libs/pam-0.78-r3 (virtual/pam) [ pam ]
           `-- sys-libs/pwdb-0.62 [ pwdb ]
           `-- dev-util/pkgconfig-0.20
           `-- sys-devel/autoconf-2.59-r7
            `-- sys-apps/texinfo-4.8-r2
             `-- sys-libs/ncurses-5.4-r6 [ !build ]
              `-- sys-libs/gpm-1.20.1-r4 [ gpm ]
            `-- sys-devel/autoconf-wrapper-3-r1
             `-- sys-devel/autoconf-2.13
              `-- sys-devel/m4-1.4.4
           `-- sys-devel/automake-1.9.6-r1
            `-- sys-devel/automake-wrapper-1-r1
             `-- sys-devel/automake-1.4_p6
              `-- sys-devel/gnuconfig-20060227
             `-- sys-devel/automake-1.5
             `-- sys-devel/automake-1.6.3
             `-- sys-devel/automake-1.7.9-r1
             `-- sys-devel/automake-1.8.5-r3
           `-- sys-devel/flex-2.5.33-r1
          `-- sys-apps/portage-2.0.54 [ !pam !sys-apps/pam-login ]
           `-- sys-apps/sed-4.1.4-r1 [ !build ]
            `-- virtual/libintl-0 (virtual/libintl) [ nls ]
           `-- dev-python/python-fchksum-1.7.1 [ !build ]
            `-- sys-libs/zlib-1.2.3
           `-- dev-lang/python-2.4.2 [ !build ]
            `-- dev-lang/tk-8.4.9 [ !dev-python/cjkcodecs X tcltk ]
             `-- x11-base/xorg-x11-6.8.2-r6 (virtual/x11)
              `-- dev-libs/expat-1.95.8
              `-- media-libs/freetype-2.1.9-r1
              `-- media-libs/fontconfig-2.2.3
              `-- x11-base/opengl-update-3.0.0 [ opengl ]
               `-- app-admin/eselect-opengl-1.0.3
                `-- app-admin/eselect-1.0
                `-- app-arch/bzip2-1.0.3-r6
              `-- media-libs/libpng-1.2.8-r1
              `-- sys-apps/groff-1.19.1-r2
              `-- sys-apps/util-linux-2.12r-r3 [ userland_GNU ]
               `-- sys-fs/e2fsprogs-1.38-r1
                `-- sys-libs/com_err-1.38
                `-- sys-libs/ss-1.38
               `-- app-crypt/hashalot-0.3-r2 [ crypt ]
               `-- sys-kernel/linux-headers-2.6.11-r2 (virtual/os-headers)
            `-- sys-libs/readline-5.1_p4 [ !dev-python/cjkcodecs ncurses readline ]
             `-- app-shells/bash-3.1_p16
            `-- sys-libs/gdbm-1.8.3-r2 [ !dev-python/cjkcodecs gdbm ]
            `-- dev-libs/openssl-0.9.7i [ !dev-python/cjkcodecs ssl ]
             `-- sys-apps/diffutils-2.8.7-r1
             `-- sys-devel/bc-1.06-r6 [ test ]
           `-- sys-apps/debianutils-2.15 [ !build userland_GNU ]
           `-- app-misc/pax-utils-0.1.10 [ !userland_Darwin ]
            `-- sys-libs/libcap-1.10-r5 [ caps ]
             `-- dev-lang/swig-1.3.21 [ !nocxx python ]
              `-- dev-java/blackdown-jdk-1.4.2.03 (virtual/jdk) [ java ]
               `-- dev-java/java-config-1.2.11-r1
               `-- media-libs/alsa-lib-1.0.10 [ alsa ]
                `-- sys-kernel/gentoo-sources-2.6.15-r1 (virtual/alsa)
                 `-- sys-devel/make-3.80-r4 [ !build ]
                 `-- sys-fs/udev-079-r1 (virtual/dev-manager)
                  `-- sys-apps/hotplug-base-20040401
                  `-- sys-apps/baselayout-1.11.14-r6
                   `-- sys-apps/sysvinit-2.86-r3
                   `-- sys-apps/coreutils-5.94-r1 [ !build !bootstrap ]
                    `-- sys-apps/help2man-1.33.1
                     `-- dev-perl/Locale-gettext-1.05 [ nls ]
                      `-- perl-core/Test-Simple-0.62
                 `-- sys-devel/binutils-2.16.1 [ !build ]
                  `-- sys-devel/binutils-config-1.8-r7
                 `-- app-text/docbook-sgml-utils-0.6.14 [ doc ]
                  `-- app-text/docbook-dsssl-stylesheets-1.79
                   `-- app-text/sgml-common-0.6.3-r4
                  `-- app-text/openjade-1.3.2-r1
                   `-- app-text/opensp-1.5.1
                  `-- dev-perl/SGMLSpm-1.03-r5
                  `-- app-text/docbook-xml-simple-dtd-4.1.2.4-r2
                   `-- app-arch/unzip-5.52
                  `-- app-text/docbook-xml-simple-dtd-1.0-r1
                   `-- dev-libs/libxml2-2.6.23
                  `-- app-text/docbook-xml-dtd-4.4-r1
                   `-- app-text/docbook-xsl-stylesheets-1.68.1-r1
                    `-- app-text/build-docbook-catalog-1.2
                  `-- app-text/docbook-sgml-dtd-3.0-r3
                  `-- app-text/docbook-sgml-dtd-3.1-r3
                  `-- app-text/docbook-sgml-dtd-4.0-r3
                  `-- app-text/docbook-sgml-dtd-4.1-r3
                  `-- app-text/jadetex-3.13-r1 [ tetex ]
                   `-- app-text/tetex-2.0.2-r8 (virtual/tetex)
                    `-- net-libs/libwww-5.4.0-r4 [ !app-text/tetex ]
                    `-- dev-util/dialog-1.0.20050206 [ !app-text/tetex !app-text/dvipdfm !dev-tex/eurosym ]
                  `-- sys-apps/which-2.16
                  `-- www-client/links-2.1_pre20 (virtual/textbrowser)
                   `-- media-libs/jpeg-6b-r5 [ jpeg ]
                    `-- sys-devel/libtool-1.5.22
                   `-- media-libs/tiff-3.7.3 [ tiff ]
                   `-- media-libs/svgalib-1.9.21-r1 [ svga ]
                    `-- sys-apps/module-init-tools-3.2.1 (virtual/modutils)
                   `-- media-libs/libsdl-1.2.8-r1 [ sdl ]
                    `-- media-libs/audiofile-0.2.6-r1 [ !noaudio ]
                    `-- media-sound/esound-0.2.36-r1 [ esd ]
                     `-- sys-apps/tcp-wrappers-7.6-r8 [ tcpd ]
                    `-- kde-base/arts-3.4.3 [ arts ]
                     `-- x11-libs/qt-3.3.4-r8
                      `-- media-libs/libmng-1.0.8-r1
                       `-- media-libs/lcms-1.14-r1
                      `-- net-print/cups-1.1.23-r7 [ cups ]
                     `-- dev-libs/glib-2.8.6
                      `-- dev-util/gtk-doc-1.4-r1 [ doc ]
                       `-- app-text/docbook-xml-dtd-4.1.2-r5
                       `-- dev-libs/libxslt-1.1.15
                        `-- dev-libs/libgcrypt-1.2.2-r1 [ crypt ]
                         `-- dev-libs/libgpg-error-1.0-r1
                       `-- app-editors/emacs-21.4-r3 (virtual/emacs) [ emacs ]
                        `-- media-libs/giflib-4.1.4
                        `-- x11-libs/Xaw3d-1.5-r1 [ !arm Xaw3d ]
                        `-- x11-libs/openmotif-2.2.3-r9 [ !arm motif !lesstif ]
                     `-- media-libs/libvorbis-1.1.0 [ vorbis ]
                      `-- media-libs/libogg-1.1.2
                     `-- media-libs/libmad-0.15.1b [ mp3 ]
                     `-- kde-base/kde-env-3-r4
                    `-- media-libs/libcaca-0.9-r1 [ libcaca ]
                     `-- media-libs/imlib2-1.2.1.009 [ imlib ]
                   `-- sys-devel/gcc-3.4.5-r1
                    `-- sys-devel/gcc-config-1.3.13-r1
                    `-- x11-libs/gtk+-2.8.12 [ !build gcj ]
                    `-- media-libs/libart_lgpl-2.3.17 [ !build ]
                `-- media-sound/alsa-headers-1.0.10
           `-- sys-apps/sandbox-1.2.12 [ !userland_Darwin ]
        `-- sys-libs/timezone-data-2006a
      `-- dev-java/blackdown-jre-1.4.2.03 (virtual/jre) [ java ]
   `-- app-text/ghostscript-esp-7.07.1-r8 (virtual/ghostscript) [ doc ]
    `-- media-fonts/gnu-gs-fonts-std-8.11
 `-- media-libs/win32codecs-20050216 [ win32codecs ]
 `-- media-video/realplayer-10.0.7 [ x86 real ]
  `-- x11-libs/pango-1.10.3 [ !amd64 ]
  `-- app-arch/rpm2targz-9.0-r3
   `-- app-arch/cpio-2.6-r5
   `-- sys-apps/file-4.13
 `-- media-sound/cdparanoia-3.9.8-r2 [ cdparanoia ]
 `-- media-libs/libdts-0.0.2-r3 [ dts ]
 `-- media-libs/libdvdread-0.9.4-r1 [ dvd dvdread ]
  `-- media-libs/libdvdcss-1.2.9
 `-- media-sound/lame-3.96.1 [ encode ]
  `-- x11-libs/gtk+-1.2.10-r11 [ gtk ]
   `-- dev-libs/glib-1.2.10-r5
   `-- dev-util/intltool-0.34.1 [ nls ]
    `-- dev-perl/XML-Parser-2.34
 `-- media-libs/libdv-0.102 [ encode dv ]
  `-- dev-libs/popt-1.7-r1

Re: [9fans] impressive

[Micah Stetson]

> while the code for autoconf has ballooned, it's support for non linux
> systems has decreased.  i believe the folk who maintain it envision it
> as a way to support a vast matrix of packages, each trying to use the
> very most bleeding edge features of the others on linux.

That may be how he intends it, but compiling on several versions of
Gentoo, Debian, and Suse isn't what I would call "ported to a wide
variety of platforms".  And if using all the backward-incompatible,
useless features of every library imaginable is what portability means
in newspeak, then portability is to blame for most of the pain of
keeping Linux systems up to date.  But then, I guess that's kind of
what he's saying (!).  You are in a maze of twisty little illogics,
all ... um ... illogical.

Micah

Re: [9fans] impressive

[erik quanstrom]

On Wed Apr 26 17:58:38 CDT 2006, rvs@sun.com wrote:
> P.S. I've kind of come to terms with the fact that working for
> Sun and porting Sun's compilers to Linux makes me a "violent minority"
> but I'm not sure whether it also makes me "pure evil" ;-)

100 Pure Evil™. ;-)

i'm sorry.  i just couldn't help it.

- erik

Re: [9fans] impressive

[Jack Johnson]

On 4/26/06, erik quanstrom <quanstro@quanstro.net> wrote:
> 100 Pure Evil™. ;-)

Now *that* is a marketing slogan!

-Jack

Re: [9fans] impressive

[jmk]

Although I have found this thread mostly trivial, today was
great. I woke up to be prompted to read the glibc FAQ, which
put a smile on my face for a good while, and now, as I prepare
to close out another otherwise depressing day, the rant about
the 'Dicatatship of the Minorities' has done it again.

Thank you. Seriously.

--jim

Re: [9fans] impressive

[erik quanstrom]

it's ironic how this guy can twist the meanings of things.  he says

	he fundamental problem is that configuration options are bad.
	Be it at runtime or at compile. Ideally there is one configuration
	which works everywhere. Every new configuration increases complexity.
	Not linearly but instead exponentially. [i'll take that to be figurative]
	Each option might influence every other option.  This is a disaster not only for users,
	but also the developers. It means exponential growth of testing. [...]


but we've all seen the code.  this is, after all, the dude that got 18 system calls inserted into
linux to support seperate threads calling chdir() and open('realative-path") independent .
good grief.  this is what arlo guthrie would call "off the edge of an edge case".

oddly i would agree but i don't know what he means by "runtime configuration".
some people might call that input.  programs, by definition, need input.

- erik

Re: [9fans] impressive

[erik quanstrom]

last i ran gcc on sun machines (or aix for that matter), glibc was
not required.  admittedly this was four years ago.  have things changed?

- erik

On Tue Apr 25 19:54:59 CDT 2006, rvs@sun.com wrote:
> On Tue, Apr 25, 2006 at 05:48:00PM -0700, geoff@collyer.net wrote:
> > >From memory and a quick scan of gcc(1) since I don't have time to read
> > the entire manual ``page'' now, `gcc -ansi -pedantic' should compile
> > exactly 1990 ISO C and `gcc --std=c99 -pedantic' should compile
> > exactly 1999 ISO C. Using -pedantic-errors instead of -pedantic will
> > produce fatal errors rather than warnings for using extensions.
>
>   gcc *can not* claim full ISO C99 compatibility for the variety of reasons,
>   but the biggest one being -- glibc is not c99 complaint.
>
> Thanks,
> Roman.

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 07:55:31PM -0500, erik quanstrom wrote:
> last i ran gcc on sun machines (or aix for that matter), glibc was
> not required.  admittedly this was four years ago.  have things changed?

  You're right with a propper libc (like Sun's) gcc has a better chance
  of being C99 complaint. Sorry I should've been clearer.

  As for the compiler itself: http://gcc.gnu.org/c99status.html

Thanks,
Roman.

Re: [9fans] impressive

[erik quanstrom]

i have not had a chance to look at dietlibc printf functions. the gnu
version is extra jumbo, and the code is very difficult to read.  but
printf is a pretty big set of functions, regardless.

it's curious that __lltostr is a different functino tha __ltostr.

as rob loves to point out, for small values of n, simple algorithms are
best.  n is usually small.  so i think it's generally a incorrect to
contrast small and fast.

- erik

On Mon Apr 24 21:50:10 CDT 2006, dfawcus@cisco.com wrote:
> On Mon, Apr 24, 2006 at 09:30:37PM -0500, erik quanstrom wrote:
> > On Mon Apr 24 21:16:57 CDT 2006, dfawcus@cisco.com wrote:
> > > glibc is bloated,  printf and strtoul are also quite large.  [..,]
> >
> > noooo.... you're kidding, right?
>
> What I meant is that relative to some other (commonly used) routines within
> dietlibc,  printf and stroul are large in object size terms.  I should have
> written the above as two sentances.
>
> The biggest things seem to be printf support, perror support,  and strtoul.
>
> __v_printf          |080484b8|   T  |              FUNC|00000773|     |.text
> __dtostr            |08048cc7|   T  |              FUNC|000003ae|     |.text
> sys_errlist         |08049650|   R  |            OBJECT|000001f8|     |.rodata
> __umoddi3           |08049400|   T  |              FUNC|000001e5|     |.text
> __udivdi3           |080492c0|   T  |              FUNC|0000013e|     |.text
> strtoul             |080482f0|   T  |              FUNC|0000010e|     |.text
> __lltostr           |080490ec|   T  |              FUNC|000000db|     |.text
> __ltostr            |080491c8|   T  |              FUNC|00000099|     |.text
> strtol              |08048268|   T  |              FUNC|00000086|     |.text
> perror              |080481ec|   T  |              FUNC|0000007a|     |.text
>
> compare to main:
>
> main                |080480bc|   T  |              FUNC|000000d6|     |.text
>
> The dietlibc versions of the algorithms have generally been written to be
> small,  rather than fast.
>
> DF

Re: [9fans] impressive

[erik quanstrom]

On Mon Apr 24 21:16:57 CDT 2006, dfawcus@cisco.com wrote:
> On Mon, Apr 24, 2006 at 02:37:21PM -0600, Ronald G Minnich wrote:
> > This program:
> >
> > compiles to a 512KB binary on linux with -static
>
> glibc is bloated,  printf and strtoul are also quite large.  [..,]

noooo.... you're kidding, right?

this is the gnu fallacy in action.  nobody can find a theoretical algorithmic weakness,
so it must be better. (my take: if it's sufficiently complicated, it can't be
criticized by anybody who understands it.  proof: nobody has enough time to understand
it. qed.)

	; wc -l /sys/src/sys/src/libc/port/strstr.c
	29 /sys/src/libc/port/strstr.c

	; wc -l $home/glibc-2.3.5/sysdeps/generic/strstr.c
	123 /home/quanstro/glibc-2.3.5/sysdeps/generic/strstr.c

the gnu strstr is really slick and exploits many tricks, but it's 4-5x bigger
than the plan 9 version.  i would venture to guess that for the common case
of smallish searches on typically cache-bound systems, the plan 9 version
beats the pants off the glibc version.  (and, if you follow the thinking through
to a whole library, you start thinking that dynamic libraries and other complicated
cheats are good ideas.)

- erik

Re: [9fans] impressive

[Derek Fawcus]

On Mon, Apr 24, 2006 at 09:30:37PM -0500, erik quanstrom wrote:
> On Mon Apr 24 21:16:57 CDT 2006, dfawcus@cisco.com wrote:
> > On Mon, Apr 24, 2006 at 02:37:21PM -0600, Ronald G Minnich wrote:
> > > This program:
> > >
> > > compiles to a 512KB binary on linux with -static
> >
> > glibc is bloated,  printf and strtoul are also quite large.  [..,]
>
> noooo.... you're kidding, right?

What I meant is that relative to some other (commonly used) routines within
dietlibc,  printf and stroul are large in object size terms.  I should have
written the above as two sentances.

The biggest things seem to be printf support, perror support,  and strtoul.

__v_printf          |080484b8|   T  |              FUNC|00000773|     |.text
__dtostr            |08048cc7|   T  |              FUNC|000003ae|     |.text
sys_errlist         |08049650|   R  |            OBJECT|000001f8|     |.rodata
__umoddi3           |08049400|   T  |              FUNC|000001e5|     |.text
__udivdi3           |080492c0|   T  |              FUNC|0000013e|     |.text
strtoul             |080482f0|   T  |              FUNC|0000010e|     |.text
__lltostr           |080490ec|   T  |              FUNC|000000db|     |.text
__ltostr            |080491c8|   T  |              FUNC|00000099|     |.text
strtol              |08048268|   T  |              FUNC|00000086|     |.text
perror              |080481ec|   T  |              FUNC|0000007a|     |.text

compare to main:

main                |080480bc|   T  |              FUNC|000000d6|     |.text

The dietlibc versions of the algorithms have generally been written to be
small,  rather than fast.

DF

[9fans] impressive

[Ronald G Minnich]

This program:

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#include <unistd.h>
#include <stdio.h>

main (int argc, char *argv[])
{
     unsigned char buf[8], *p;
     int fd_msr, i;
     unsigned long addr = 0;

     if (argc < 3) {
         printf("usage:wrmsr reg value\n");
         exit(1);
     }
     addr = strtoul(argv[1], NULL, 0);
     p = argv[2];

     printf("MSR register 0x%lx => ", addr);
     for (i = 7; i > 0; i--) {
         buf[i] = strtol(p, &p, 16);
         p++;
         printf("%2.2x:", buf[i]);
     }
     buf[i] = strtol(p, &p, 16);
     printf("%2.2x\n", buf[i]);

     fd_msr = open("/dev/cpu/0/msr", O_WRONLY);
     lseek(fd_msr, addr, SEEK_SET);
     if (write(fd_msr, buf, 8) < 0)
         perror("");
}

compiles to a 512KB binary on linux with -static

Well, *I'm* impressed anyway.

[[ standard old guy story about "my first Unix box" and "nobody knows
the value of 2 bits anymore" and "what's with these GNU kids today"
deleted -- ed.]]

yy* symbols are in there btw. And, don't worry, some pthreads symbols
made it in as well. Don't want main() to be too lonely!

ron

Re: [9fans] impressive

[Charles Forsyth]

> compiles to a 512KB binary on linux with -static

i can see now why they were so concerned to conserve tlb entries
by avoiding such wickedness as private stacks.  that's a good chunk.

Re: [9fans] impressive

[Brantley Coile]

> compiles to a 512KB binary on linux with -static

I feel cheated!  I only get 100K!  Of course that's on a
FreeBSD system.  On the Linux I got my half megabyte.
On OS X I get the message mentioned earlier:

/usr/bin/ld: can't locate file for: -lcrt0.o

Re: [9fans] impressive

[Anthony Sorace]

On 4/24/06, Brantley Coile <brantley@coraid.com> wrote:
> On OS X I get the message mentioned earlier:
>
> /usr/bin/ld: can't locate file for: -lcrt0.o

works fine for me (coming in at a comparatively puny 17,936 bytes).
i've seen the crt0.o error plenty of times, and it's always been due
to having an outdated version of the dev tools (Xcode Tools or
whatever) installed.

Re: [9fans] impressive

[Anthony Sorace]

On 4/25/06, Anthony Sorace <anothy@gmail.com> wrote:
> works fine for me...

um, nope. ignore that. too early in the morning.

Re: [9fans] impressive

[Derek Fawcus]

On Mon, Apr 24, 2006 at 02:37:21PM -0600, Ronald G Minnich wrote:
> This program:
>
> compiles to a 512KB binary on linux with -static

glibc is bloated,  printf and strtoul are also quite large.  Try dietlibc

; diet gcc -c -Os testit.c
; size testit.o
   text    data     bss     dec     hex filename
    289       0       0     289     121 testit.o
; diet gcc -o testit -s -Os testit.c
; size testit
   text    data     bss     dec     hex filename
   9620       0      12    9632    25a0 testit

So the libraries come to over 9k,  and there is still some
crud in the image:

; objdump -h testit

testit:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00001548  080480a0  080480a0  000000a0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .rodata       00000ff4  08049600  08049600  00001600  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .data         00000000  0804b5f4  0804b5f4  000025f4  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .eh_frame     00000058  0804b5f4  0804b5f4  000025f4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .bss          0000000c  0804b650  0804b650  00002650  2**3
                  ALLOC
  5 .comment      0000005d  00000000  00000000  00002650  2**0
                  CONTENTS, READONLY

Why do I need an exception handler frame (assuming that is what
the name means)?

DF

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 03:15:23AM +0100, Derek Fawcus wrote:
> On Mon, Apr 24, 2006 at 02:37:21PM -0600, Ronald G Minnich wrote:
> > This program:
> >
> > compiles to a 512KB binary on linux with -static
>
> glibc is bloated,  printf and strtoul are also quite large.  Try dietlibc

  There's also uclibc..

> Why do I need an exception handler frame (assuming that is what
> the name means)?

  Well, this is to unwind trough exceptions through the C stack:
  foo_cpp() calls bar() calls  ex_cpp() where ex_cpp() and foo_cpp()
  are written in C++ and bar is written in C. If you have .eh_frame
  in place an exception thrown from ex_cpp() can properly reach
  foo_cpp().

  But stop complaining! Next thing you know -- there'll be Java ByteCode
  stashed in .java_byte_code_in_case_you_needed_it section!

Thanks,
Roman.

P.S. I wish the last one was a joke :-(

Re: [9fans] impressive

[Derek Fawcus]

On Mon, Apr 24, 2006 at 07:23:29PM -0700, Roman Shaposhnick wrote:
> On Tue, Apr 25, 2006 at 03:15:23AM +0100, Derek Fawcus wrote:
> > On Mon, Apr 24, 2006 at 02:37:21PM -0600, Ronald G Minnich wrote:
> > > This program:
> > >
> > > compiles to a 512KB binary on linux with -static
> >
> > glibc is bloated,  printf and strtoul are also quite large.  Try dietlibc
>
>   There's also uclibc..
>
> > Why do I need an exception handler frame (assuming that is what
> > the name means)?
>
>   Well, this is to unwind trough exceptions through the C stack:

There is no c++ code here,  last I looked there is no c++ in dietlibc.

I assume this must just be gcc being paranoid,  now if only I can
find the flag to remove this (other than using strip/objcopy as a hammer).

>   But stop complaining! Next thing you know -- there'll be Java ByteCode
>   stashed in .java_byte_code_in_case_you_needed_it section!

Well I always find the .comment sections annoying,  lots of junk saying
which version of gcc compiled a given module...

DF

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 03:37:04AM +0100, Derek Fawcus wrote:
> >   Well, this is to unwind trough exceptions through the C stack:
>
> There is no c++ code here,  last I looked there is no c++ in dietlibc.

  That's the beauty of a shared library -- you never know who might
  end up calling you, and if you have routines which do call back --
  you never know what awaits you there as well. So, these days
  for a perfectly law-abiding pureC shared library which defines
  bar() (from my example) there must be a .eh_frame section to
  make C++ applications (the ones calling bar() by the virtue of
  dynamic linking) feel better.

> Well I always find the .comment sections annoying,  lots of junk saying
> which version of gcc compiled a given module...

  Well, at least for those you can use mcs(1) but .eh_frame was made
  mandatory by the AMD64 ABI.

Thanks,
Roman.

Re: [9fans] impressive

[Derek Fawcus]

On Mon, Apr 24, 2006 at 08:51:17PM -0700, Roman Shaposhnick wrote:
> On Tue, Apr 25, 2006 at 03:37:04AM +0100, Derek Fawcus wrote:
> > >   Well, this is to unwind trough exceptions through the C stack:
> >
> > There is no c++ code here,  last I looked there is no c++ in dietlibc.
>
>   That's the beauty of a shared library

Well it must be junk in the linker script,  I just can't be bothered to
track it down and fix it.  This section is not in the .o;  and the output
was a static file.  So there is no call for the .eh_frame as this is not
an AMD64 - it is a plain old 32 bit x86.

DF

Re: [9fans] impressive

[Roman Shaposhnick]

On Tue, Apr 25, 2006 at 09:17:01AM +0100, Derek Fawcus wrote:
> On Mon, Apr 24, 2006 at 08:51:17PM -0700, Roman Shaposhnick wrote:
> > On Tue, Apr 25, 2006 at 03:37:04AM +0100, Derek Fawcus wrote:
> > > >   Well, this is to unwind trough exceptions through the C stack:
> > >
> > > There is no c++ code here,  last I looked there is no c++ in dietlibc.
> >
> >   That's the beauty of a shared library
>
> Well it must be junk in the linker script,  I just can't be bothered to
> track it down and fix it.  This section is not in the .o;  and the output
> was a static file.  So there is no call for the .eh_frame as this is not
> an AMD64 - it is a plain old 32 bit x86.

  You can call it whatever you want. I explained the reasons it is there.
  On top of which I can add that it *is* helpful to have .eh_frame if
  any of your callers can be C++. Since I don't understand what part of the
  explanation you don't understand the last thing I can add to this
  conversation is that there are 2 kind of exception related sections
  generate by two different components:

     * .eh_frame is generate by the compiler (and these days even by the
     C compiler running on arcs which don't strictly require it) and has
     tables describing the stack layout and such. It is actually based
     on DWARF2 and is rather difficult to get rid of, unless you want
     to write linker scripts or use objcopy.

     * .eh_frame_hdr is generated by the GNU ld when it sees --eh-frame-hdr
     and has index for facilitating binary searches inside the actual
     .eh_frame sections. This one you can skip by making sure GNU ld
     is not given --eh-frame-hdr.

Thanks,
Roman.

Re: [9fans] impressive

[Derek Fawcus]

Anyway,  I found the culprit - libgcc has modules compiled with exception
handling sections;  __udivdi3 and __umoddi3 get pulled from there.

Mind there is a separate libgcc.a and libgcc_eh.a;  I'm not sure what
the difference is supposed to be (the latter is about half the size).

DF

Re: [9fans] impressive

[Roman Shaposhnick]

On Wed, Apr 26, 2006 at 02:11:32AM +0100, Derek Fawcus wrote:
> Anyway,  I found the culprit - libgcc has modules compiled with exception
> handling sections;  __udivdi3 and __umoddi3 get pulled from there.

  Well, how exactly does it relate to the original topic where we
  were discussing glibc ? libgcc is not part of glibc.

> Mind there is a separate libgcc.a and libgcc_eh.a;  I'm not sure what
> the difference is supposed to be (the latter is about half the size).

  libgcc.a	-	Support routines, not including EH
  libgcc_eh.a	-	EH support routines
  libgcc_s.so	-	Support routines, including EH

Thanks,
Roman.

Re: [9fans] impressive

[Derek Fawcus]

On Tue, Apr 25, 2006 at 06:19:33PM -0700, Roman Shaposhnick wrote:
> On Wed, Apr 26, 2006 at 02:11:32AM +0100, Derek Fawcus wrote:
> > Anyway,  I found the culprit - libgcc has modules compiled with exception
> > handling sections;  __udivdi3 and __umoddi3 get pulled from there.
>
>   Well, how exactly does it relate to the original topic where we
>   were discussing glibc ? libgcc is not part of glibc.

It relates to the sub thread where I linked the program with dietlibc
rather than with glibc,  got a more sensible sized program,  and was
then trying to figure out where the .eh_frame section came from.

The compiler I'm using does not generate .eh_frame sections by default,
so neither the testit.o file (compiled from the posted C source) nor
the input .o files from dietlibc contain such sections.

Hence my assertion that it was something the linker was doing,  I had
forgotten about the existance of libgcc.  Now that I know where it is
coming from,  I can ignore it.

While the info you supplied was interesting,  it did not directly relate
to what I was trying to figure out.

> > Mind there is a separate libgcc.a and libgcc_eh.a;  I'm not sure what
> > the difference is supposed to be (the latter is about half the size).
>
>   libgcc.a	-	Support routines, not including EH
>   libgcc_eh.a	-	EH support routines
>   libgcc_s.so	-	Support routines, including EH

Well maybe Suse messed up,  or the compiler is simply old enought to be
doing stuff differently.

This machine does not have the .so,  the _eh.a contains a bunch of unwind
routines,  and the objects within libgcc.a have been compiled to include
.eh_frame sections. (GCC 3.3.3)

However the mips64 crosscompiler version of gcc 3.4.4 that I compiled up,
only has libgcc.a,  and it also has .eh_frame sections in the same objects.
Looking at the C source for them,  there would not appear to be any good
reason for these to have EH info - they don't call anything else.

So it just looks like GCC is always compiling the div/mod helper routines
with .eh_frame sections requested.

DF

Re: [9fans] impressive

[Andy Newman]

I like this quote from the glibc FAQ...

    1.2. What compiler do I need to build GNU libc?

    ...  A lot of extensions of GNU CC are used to increase portability ...

Re: [9fans] impressive

[Ronald G Minnich]

Andy Newman wrote:
> I like this quote from the glibc FAQ...
>
>     1.2. What compiler do I need to build GNU libc?
>
>     ...  A lot of extensions of GNU CC are used to increase portability ...
>

that explains computed goto.

ron

Re: [9fans] impressive

[Dan Cross]

On Tue, Apr 25, 2006 at 01:02:30PM +1000, Andy Newman wrote:
> I like this quote from the glibc FAQ...
>
>     1.2. What compiler do I need to build GNU libc?
>
>     ...  A lot of extensions of GNU CC are used to increase portability ...

I remember a year or two picking up a Linux rag at the train station on the
way back from somewhere.  They were talking about gcc 4 or something in it
and saying how they were hoping to do away with a lot of GNU extensions by
stricter adherence to the language standards in the compiler itself; I guess
that work got buried.  Then again, this was a cursory read on the Subway,
and I'm slightly dyslexic, so maybe  read it the opposite way it was meant.

	- Dan C.