Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[quanstro]

On Mon Feb 13 14:27:01 CST 2006, rminnich@lanl.gov wrote:
> 
> I don't think that there is a PDP-10 port, though that might be closest 
> in some ways: no mmap, no real stuff from post-1981 Unix really, pretty 
> simple interface. GNU supports a rich variety of targets; what one is 
> most like Plan 9? QNX? VXworks? ECOS? Maybe DOS? I am not sure.
> 
[...]
> 
> The reason I wanted to start with gcc 0.9, a few years ago, was that in 
> the early days gcc would compile under just about any OS and C compiler 
> -- the newer gcc's only seem to compile under gcc. So you start with gcc 
> 0.9, get it to build under native plan 9, not APE, then bootstrap your 
> way forward to current. I have no idea if this will work, but I did 
> bootstrap gcc onto a lot of weird machines 15 years ago. It looks much 
> harder, however, to drop gcc 4.0 onto a non-gcc-like C compiler and get 
> it to go!

gcc 1.32 compiled on bsd 4.3 for me back in the day. that should cover 
the "no mmap" etc.

also, perhaps tcc could bootstrap gcc? i know it has been used to compile
the linux kernel, so it should be up to the task on x86-compatables.

- erik

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[quanstro]

i have installed gentoo on a 128M ibm thinkpad 570.
the only annoyance is that gentoo is built for pIII by default and
i had to recompile X. it only took 28 hrs.

- erik

On Tue Feb 14 03:49:05 CST 2006, forsyth@terzarima.net wrote:
> ron is right: supposedly `portable' programs are full of gcc-specific stuff.
> much of it is fairly silly.   if you google, somewhere there's a description of
> the unbelievable mess connected with strcmp and strncmp semi-builtins.  staggering.
> 
> it's much easier just to regard a gcc-based environment as another
> world (which is what is, anyway) and let it be self-contained (as well
> as self-centred).  at least plan 9 doesn't care what you do in user
> space, unlike some other systems.
> 
> mind you, i'd be happier if linux could run its own programs.
> on a 192mbyte machine with an off-the-cd (errr. dvd) installation,
> apt-get can't update anything because it has exhausted the mmap mappings.
> i'm exhausted too.  i'll just reinstall.  i'll try ubuntu this time, that seems to work better.
> 

[9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[uriel]

> total applied/ape-dumb-autohell-fixes
> drwxrwxr-x 1 uriel sys 0 Feb 13 09:35 applied/ape-dumb-autohell-fixes
> from uriel@cat-v.org
> 	/rc/bin/ape/printf
> 	/sys/src/ape/cmd/ls.c
> 	Small 'fixes' to APE to make auto*hell a bit happier.
> 	
> 	Had to create a fork of ls to better emulate Unix ls:
> 	Auto*hell tries to use ls -L because some sort of symlink braindamage
> 	which obviously doesn't apply to Plan 9, allow that flag but ignore it.
> 	
> 	Auto hell does some weird tests comparing the arguments it gives to ls
> 	with the output of ls, cleanname() breaks those tests by rewriting parts
> 	of the path, so removed the calls to cleanname().
> 	
> 	Auto*hell also often calls printf with a single argument and no formating,
> 	so I created a really dummy printf that just prints it's first argument.
> 	
> 	This patch is not of much value, but when trying to wade thru auto*hell
> 	land it removes lots of noise. Further patches might follow as I go thru
> 	the experience of trying to get a single auto*hell script to run, if I
> 	don't go mad first.
> 
> Mon Feb 13 09:31:40 EST 2006 rsc
>     I put in a shell script to simulate Unix ls better.
>     I do not want to fork ls.  
That is what I did at first, but then I hit a wall, eg.,:

% grep '\$srcdir/configure' SDL-1.2.9/configure
   set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
      set X `ls -t $srcdir/configure conftest.file`
   if test "$*" != "X $srcdir/configure conftest.file" \
      && test "$*" != "X conftest.file $srcdir/configure"; then

($srcdir is '.')

I don't like the idea of forking stuff, but in the end it's going to be the only
way if APE is going to emulate all the lunix crap well enough to be useful.

>     I do not believe that cleanname needs to come out.
>     I used to run ./configure scripts all the time without
>     needing to touch ls.
Maybe it's a recent "improvement" to the auto*hell world.

uriel

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Russ Cox]

> % grep '\$srcdir/configure' SDL-1.2.9/configure
>    set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
>       set X `ls -t $srcdir/configure conftest.file`
>    if test "$*" != "X $srcdir/configure conftest.file" \
>       && test "$*" != "X conftest.file $srcdir/configure"; then
>
> ($srcdir is '.')

I think this is just a bug in the Plan 9 ls.  It uses
cleanname as a crutch to avoid doubling / in some names,
but that makes it somewhat inconsistent.  For example:

    cd /sys/src/cmd
    ls . | grep ls.c
    ls ./ls.c

produces two different lines.

I put a new ls.c on sources that is a bit more consistent
and should work better in the above script.

> I don't like the idea of forking stuff, but in the end it's going to be the only
> way if APE is going to emulate all the lunix crap well enough to be useful.

Says you.  I think having wrappers (as we do for yacc and ar)
is a much better long-term approach.  Then there's still only
one program providing the core functionality.

Also, just to be clear, APE is the Ansi/Posix Environment,
not the "Any random craP that linux does Environment".
The configure scripts that autoconf writes are written to
the intersection of pretty much every Unix out there,
so if there's something they expect (like mkdir -p or ls -L)
then it's worth adding.  But compatibility with GNU/Linux
is *not* the goal.

> >     I do not believe that cleanname needs to come out.
> >     I used to run ./configure scripts all the time without
> >     needing to touch ls.
> Maybe it's a recent "improvement" to the auto*hell world.

I don't really see the point to incendiary names like auto*hell.
Are you just trying to make yourself feel better?

Russ

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[uriel]

> I think this is just a bug in the Plan 9 ls.  It uses
> cleanname as a crutch to avoid doubling / in some names,
> but that makes it somewhat inconsistent.  For example:
> 
>     cd /sys/src/cmd
>     ls . | grep ls.c
>     ls ./ls.c
> 
> produces two different lines.

Yes, as I commented in irc, that was somewhat confusing, but I thought
it was 'by design'.

> I put a new ls.c on sources that is a bit more consistent
> and should work better in the above script.

Cool.  It works for that test, but still ls output in Plan 9 is
different from Unix: in unix if the argument is a directory, it will
only print the file names instead of the full path, but it will
preserve any amount of // and /./ in the path if the argument is a
file.  But I think that can be emulated with wrapper script if that is
ever a problem(I wouldn't bother trying to emulate it for now).

> Says you.  I think having wrappers (as we do for yacc and ar)
> is a much better long-term approach.  Then there's still only
> one program providing the core functionality.

I agree that when possible, a wrapper is the best solution.
 
> Also, just to be clear, APE is the Ansi/Posix Environment,
> not the "Any random craP that linux does Environment".
> The configure scripts that autoconf writes are written to
> the intersection of pretty much every Unix out there,
> so if there's something they expect (like mkdir -p or ls -L)
> then it's worth adding.  But compatibility with GNU/Linux
> is *not* the goal.

GNU/Linux is what all Unixes try to emulate as closely as possible
this days; but I agree aiding portability is the main goal of APE, not
gratuitous emulation of various GNU/braindamage like BSDs fashion so
much this days.

>> Maybe it's a recent "improvement" to the auto*hell world.
> 
> I don't really see the point to incendiary names like auto*hell.
> Are you just trying to make yourself feel better?

Yes, any way to release the frustration produced by messing with that
abomination helps.  I also punch the screen and bang my head
against the keyboard. 

Although it's starting to reach the level of Perl, where it becomes
impossible to take it seriously anymore and one starts to take it as
an hysterical parody.

uriel

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Russ Cox]

> GNU/Linux is what all Unixes try to emulate as closely as possible
> this days.

If this is true, then they're doing an amazingly bad job!

At least the systems I use regularly (FreeBSD, OS X, Solaris, Irix)
don't come anywhere near emulating GNU/Linux.  Any similarity
is due to common ancestry, not imitation.

Russ

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Lyndon Nerenberg]

> GNU/Linux is what all Unixes try to emulate as closely as possible
> this days;


Excuse me?

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Ronald G Minnich]

Lyndon Nerenberg wrote:
>> GNU/Linux is what all Unixes try to emulate as closely as possible
>> this days;
> 
> 
> 
> Excuse me?

hmm. What uriel may be saying is that a lot of open source software, 
allegedly portable, is really only "portable" to different Linux 
distros. I have seen this more and more in recent years. Just take any 
of a dozen chunks of "portable" code and try to build it on mac osx, for 
example. All too often, if tails.

It is also the case that some non-Linux OSes have felt pressure to add 
Linux-like features ...

ron

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Lyndon Nerenberg]

> hmm. What uriel may be saying is that a lot of open source software,
> allegedly portable, is really only "portable" to different Linux
> distros. I have seen this more and more in recent years. Just take
> any of a dozen chunks of "portable" code and try to build it on mac
> osx, for example. All too often, if tails.

But you fairly quickly learn what these Linuxisms are, and how to undo 
them.  I own a Mac, and deal with this on a regular basis.  Most of the 
time I find the most non-portable part of the whole is 
autoconf/configure.  Somewhat ironic, don't you think?  In my view, 
autoconf has become a caricature of itself.

One reason why I like to keep a Solaris machine around is to have a 
completely non-GNU compiler toolchain handy.  That makes it easy to weed 
this nonsense out.  POSIX may be braindead in a lot of ways, but if used 
with common sense it does allow for widely portable code.  For the vast 
majority of applications software, there really isn't any need for 
autoconf in this day and age.

> It is also the case that some non-Linux OSes have felt pressure to
> add Linux-like features ...

Add? Or emulate.  FreeBSD and Solaris both support runtime emulation of 
Linux.  This doesn't mean Linux is taking over the core OS (thank God). 
  I don't have a problem with anyone providing runtime ABI compatibility 
for Linux applications, since it doesn't infect the core OS environment.

--lyndon

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Ronald G Minnich]

Lyndon Nerenberg wrote:

> But you fairly quickly learn what these Linuxisms are, and how to undo 
> them.  I own a Mac, and deal with this on a regular basis.  Most of the 
> time I find the most non-portable part of the whole is 
> autoconf/configure.  Somewhat ironic, don't you think?  In my view, 
> autoconf has become a caricature of itself.

the part I like best is when you can't autoconf something because the 
autoconf tools are old :-)
ron

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[David Leimbach]

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

On 2/13/06, Ronald G Minnich <rminnich@lanl.gov> wrote:
>
> Lyndon Nerenberg wrote:
> >> GNU/Linux is what all Unixes try to emulate as closely as possible
> >> this days;
> >
> >
> >
> > Excuse me?
>
> hmm. What uriel may be saying is that a lot of open source software,
> allegedly portable, is really only "portable" to different Linux
> distros. I have seen this more and more in recent years. Just take any
> of a dozen chunks of "portable" code and try to build it on mac osx, for
> example. All too often, if tails.


This seems very true... For better or worse, I've got KDE commit bits from a
long time ago [well for me anyway].  I have always tried to use FreeBSD as
my main development platform but it never seems to pan out well for me.  The
code has gotten better in that a lot of modules either don't rely on a piece
of seemingly "linux-only" software [like cdparanoia, I don't think that's a
requirement for CD ripping anymore, that or they ported it to FreeBSD as
some point].

The problem compounds itself when big projects shoot for reusing other
smaller project's code.  Code that probably only works on Linux and due to
hardwired ioctl calls or something can't be easily ported to other OSes.



It is also the case that some non-Linux OSes have felt pressure to add
> Linux-like features ...


Like new ioctl calls, or linux compatibility layers.


ron
>

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

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Ronald G Minnich]

Russ raises an interesting point, which if I understand it correctly, is 
that we are not trying to emulate linux, we are trying to get the gnu 
stuff to run. The difference is important. The question is, which GNU 
target most resembles today's plan 9 environment? I don't mean APE by 
that, I mean the real Plan 9 environment.

I don't think that there is a PDP-10 port, though that might be closest 
in some ways: no mmap, no real stuff from post-1981 Unix really, pretty 
simple interface. GNU supports a rich variety of targets; what one is 
most like Plan 9? QNX? VXworks? ECOS? Maybe DOS? I am not sure.

(I am not trying to be insulting by mentioning DOS. I am mentioning it 
as a possible least common denominator.)

I've always had the hope that we could somehow bootstrap some version of 
the gcc toolchain, get liberty up, and ease into it that way -- but not 
under APE! Try to find a way to do a native plan 9 version of gnu tools. 
The reason is simple: I have lots of interest in Plan 9, but the code 
bases for the apps all need GCC/G++. This is a huge barrier.

The reason I wanted to start with gcc 0.9, a few years ago, was that in 
the early days gcc would compile under just about any OS and C compiler 
-- the newer gcc's only seem to compile under gcc. So you start with gcc 
0.9, get it to build under native plan 9, not APE, then bootstrap your 
way forward to current. I have no idea if this will work, but I did 
bootstrap gcc onto a lot of weird machines 15 years ago. It looks much 
harder, however, to drop gcc 4.0 onto a non-gcc-like C compiler and get 
it to go!

Please don't tell me that the codes are dumb and people who use gcc are 
dumb. Code bases such as the ones I deal with are the result, in some 
cases, of decades of work, some of them written by people smarter than 
anyone you'll ever know. It's just not practical to say 'dump that 
code'. This portability issue is a major problem for Plan 9 usage where 
I work.

Also, for what it is worth, almost all the code deals with system calls 
no more complex than open/read/write/close. futex is not an issue!

thanks

ron

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Steve Simon]

> The reason is simple: I have lots of interest in Plan 9, but the code 
> bases for the apps all need GCC/G++. This is a huge barrier.

I want to understand but don't, what features of GCC are
required?

> Also, for what it is worth, almost all the code deals with system calls 
> no more complex than open/read/write/close. futex is not an issue!

This infers that APEs libc is enough for these apps. Is it just 
__attribute__() stuff, or the last ½% efficency?

Personally I would like to have gcc-arm9 as this is what we use
for our embedded systems and unfortunately 5c uses a different
calling convention.

-Steve

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Paul Lalonde]

On 13-Feb-06, at 12:47 PM, Steve Simon wrote:
> I want to understand but don't, what features of GCC are
> required?

C++, for better or for worse.  Too much code (including most of what  
I have to work with) is C++.  And although the language is a dog's  
breakfast, there are some important developments that have made it in  
there that aren't in C.  Generics and language-supported polymorphism  
are both useful, particularly if your trade is providing users with  
extensible abstractions of hardware they can't understand well enough.

Paul

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Steve Simon]

> C++, for better or for worse. 

Ah, yes, that, I was being really dim.

-Steve

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Ronald G Minnich]

Steve Simon wrote:
>>The reason is simple: I have lots of interest in Plan 9, but the code 
>>bases for the apps all need GCC/G++. This is a huge barrier.
> 
> 
> I want to understand but don't, what features of GCC are
> required?

all of them :-)

all that pragma junk -- align, packed, etc. This is in the source, not 
the -fwhatever stuff.


ldscript stuff.

It's a long and depressing list.


> This infers that APEs libc is enough for these apps. Is it just 
> __attribute__() stuff, or the last ½% efficency?

I just don't want to go APE long term. It's more a question of taste though.

ron

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[andrey mirtchovski]

>
> I've always had the hope that we could somehow bootstrap some  
> version of the gcc toolchain, get liberty up, and ease into it that  
> way -- but not under APE! Try to find a way to do a native plan 9  
> version of gnu tools. The reason is simple: I have lots of interest  
> in Plan 9, but the code bases for the apps all need GCC/G++. This  
> is a huge barrier.
>

ftp.gnu.org has 1.42 as the earliest:

# cc -g   -o gccnew gcc.o version.o obstack.o alloca.o
# gccnew -v
gcc version 1.42
#

*waves at uriel*

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Latchesar Ionkov]

On Mon, Feb 13, 2006 at 01:21:22PM -0700, Ronald G Minnich said:
> 
> The reason I wanted to start with gcc 0.9, a few years ago, was that in 
> the early days gcc would compile under just about any OS and C compiler 
> -- the newer gcc's only seem to compile under gcc. So you start with gcc 
> 0.9, get it to build under native plan 9, not APE, then bootstrap your 
> way forward to current. I have no idea if this will work, but I did 
> bootstrap gcc onto a lot of weird machines 15 years ago. It looks much 
> harder, however, to drop gcc 4.0 onto a non-gcc-like C compiler and get 
> it to go!

I think it is much easier to build cross-compiler of the latest gcc version
on some other OS and then use it to build the native Plan9 version.

> ldscript stuff.

You want to use GNU binutils? It would be very hard to make GNU binutils to
support Plan9 object file format. The options are to use ?c/?l/acid and lose
the GNU binutils features, or to use some object format supported by GNU
binutils and compile everything (even the kernel ;) with gcc and gnu binutils.

Thanks,
	Lucho

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Paul Lalonde]

On 13-Feb-06, at 4:39 PM, Latchesar Ionkov wrote:
> You want to use GNU binutils? It would be very hard to make GNU  
> binutils to
> support Plan9 object file format. The options are to use ?c/?l/acid  
> and lose
> the GNU binutils features, or to use some object format supported  
> by GNU
> binutils and compile everything (even the kernel ;) with gcc and  
> gnu binutils.

It's even deeper than that; since plan9 doesn't use the target  
platform ABIs, it's not even possible to write an elf-to-plan9  
executable converter; GCC would have to be customized to generate  
code to plan9's calling convention and probably object format.  Even  
though libBFD is used it hardcodes a lot of incompatible assumptions  
about object file layout - in particular, I don't think it can  
represent plan9's .o/.S hybrid format.

It's a way bigger project than it looks like on the surface.

Paul

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Latchesar Ionkov]

Dhog's gcc port uses some (I don't remember which one) GNU binutils
compatible object format. The drawback is that you need to compile
everything with gcc and you have to use gdb to debug the programs.

Long time ago I started porting gcc to use 8a for .o generation. I got most
of the C support working, but then I got distracted and didn't finish the
C++ part. IIRC there were some changes required in 8a/8l for the exception
handling support.

Thanks,
	Lucho

On Mon, Feb 13, 2006 at 04:41:51PM -0800, Paul Lalonde said:
> 
> On 13-Feb-06, at 4:39 PM, Latchesar Ionkov wrote:
> >You want to use GNU binutils? It would be very hard to make GNU  
> >binutils to
> >support Plan9 object file format. The options are to use ?c/?l/acid  
> >and lose
> >the GNU binutils features, or to use some object format supported  
> >by GNU
> >binutils and compile everything (even the kernel ;) with gcc and  
> >gnu binutils.
> 
> It's even deeper than that; since plan9 doesn't use the target  
> platform ABIs, it's not even possible to write an elf-to-plan9  
> executable converter; GCC would have to be customized to generate  
> code to plan9's calling convention and probably object format.  Even  
> though libBFD is used it hardcodes a lot of incompatible assumptions  
> about object file layout - in particular, I don't think it can  
> represent plan9's .o/.S hybrid format.
> 
> It's a way bigger project than it looks like on the surface.
> 
> Paul

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Joel Salomon]

On 2/13/06, Latchesar Ionkov <lucho@gmx.net> wrote:
> You want to use GNU binutils? It would be very hard to make GNU binutils to
> support Plan9 object file format. The options are to use ?c/?l/acid and lose
> the GNU binutils features, or to use some object format supported by GNU
> binutils and compile everything (even the kernel ;) with gcc and gnu binutils.

Why would that be?  Don't ?l use (a variant of) the a.out format?

--Joel

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Joel Salomon]

On 2/13/06, Joel Salomon <joelcsalomon@gmail.com> wrote:
> Why would that be?  Don't ?l use (a variant of) the a.out format?

And I'm pretty sure that ELF, a.out, and the Windows format (COFF?)
are well supported by binutils.

--Joel

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Latchesar Ionkov]

On Mon, Feb 13, 2006 at 07:50:05PM -0500, Joel Salomon said:
> On 2/13/06, Latchesar Ionkov <lucho@gmx.net> wrote:
> > You want to use GNU binutils? It would be very hard to make GNU binutils to
> > support Plan9 object file format. The options are to use ?c/?l/acid and lose
> > the GNU binutils features, or to use some object format supported by GNU
> > binutils and compile everything (even the kernel ;) with gcc and gnu binutils.
> 
> Why would that be?  Don't ?l use (a variant of) the a.out format?

IIRC ?l produces executable that is a.out variant, but the input object
files are very different than the .o files binutils support. Plan9 object
files are binary encoded assembler instructions.

	Lucho

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Joel Salomon]

On 2/13/06, Latchesar Ionkov <lucho@gmx.net> wrote:
> IIRC ?l produces executable that is a.out variant, but the input object
> files are very different than the .o files binutils support. Plan9 object
> files are binary encoded assembler instructions.

I'd forgotten about that.

How hard would a Plan 9 assembler <-> GAS format conversion be?

--Joel

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Charles Forsyth]

ron is right: supposedly `portable' programs are full of gcc-specific stuff.
much of it is fairly silly.   if you google, somewhere there's a description of
the unbelievable mess connected with strcmp and strncmp semi-builtins.  staggering.

it's much easier just to regard a gcc-based environment as another
world (which is what is, anyway) and let it be self-contained (as well
as self-centred).  at least plan 9 doesn't care what you do in user
space, unlike some other systems.

mind you, i'd be happier if linux could run its own programs.
on a 192mbyte machine with an off-the-cd (errr. dvd) installation,
apt-get can't update anything because it has exhausted the mmap mappings.
i'm exhausted too.  i'll just reinstall.  i'll try ubuntu this time, that seems to work better.

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Brantley Coile]

> it's much easier just to regard a gcc-based environment as another
> world (which is what is, anyway) and let it be self-contained (as well
> as self-centred).

That has my vote.

A bunch of New Yorker discovered Miami in the 1920's.  It was a paradise!
All they needed to do to make it perfect was cut down all the palm trees,
pave over the sand dunes and build tall buildings that look just like
New York.

Then they all moved to L. A.

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Ronald G Minnich]

Brantley Coile wrote:
>>it's much easier just to regard a gcc-based environment as another
>>world (which is what is, anyway) and let it be self-contained (as well
>>as self-centred).
> 
> 
> That has my vote.

actually, I think I was thinking this too. gcc would be its own world 
right down to the system call level. No ?a or ?l compatibility issues; 
you don't use them. Convert gcc calling conventions to plan 9 calling 
conventions at the kernel interface (I had to do stuff like this for Xen 
...)

So, if gcc is driving gas and gld, then the only issue is generating 
plan 9 a.out format. libbfd can be taught to do this.

ron

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Russ Cox]

> actually, I think I was thinking this too. gcc would be its own world 
> right down to the system call level. No ?a or ?l compatibility issues; 
> you don't use them. Convert gcc calling conventions to plan 9 calling 
> conventions at the kernel interface (I had to do stuff like this for Xen 
> ...)
> 
> So, if gcc is driving gas and gld, then the only issue is generating 
> plan 9 a.out format. libbfd can be taught to do this.

David Hogan did exactly this.  Sure, it uses an APE-like library,
but if all you want is open/read/write/close, who cares?
/n/sources/extra/gcc

Russ

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[Ronald G Minnich]

Russ Cox wrote:

> David Hogan did exactly this.  Sure, it uses an APE-like library,
> but if all you want is open/read/write/close, who cares?
> /n/sources/extra/gcc

Then the only thing needed to close the loop is get the mods back to 
FSF-land. Ah well, I will take a look at this stuff as soon as I can.

thanks

ron

Re: [9fans] Re: patch/list applied/ape-dumb-autohell-fixes

[David Leimbach]

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

>
> The reason I wanted to start with gcc 0.9, a few years ago, was that in
> the early days gcc would compile under just about any OS and C compiler
> -- the newer gcc's only seem to compile under gcc. So you start with gcc
> 0.9, get it to build under native plan 9, not APE, then bootstrap your
> way forward to current. I have no idea if this will work, but I did
> bootstrap gcc onto a lot of weird machines 15 years ago. It looks much
> harder, however, to drop gcc 4.0 onto a non-gcc-like C compiler and get
> it to go!



If this ever worked, this should still work right, just possibly with
several bootstrapped stages to get to that point.

I think the real danger in doing this is getting someone who wants to be a
GNU maintainer/defender of the Plan 9 platform.  I've no interest to ever
look under the hood of the GNU compiler collection personally, but I can see
the value in having this available on Plan 9.

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