Re: [MiNT] obsolete aout binutils?

[Mark Duckworth <mduckworth@atari-source.com>]

On Mon, 2005-08-08 at 20:55 +0200, Patrice Mandin wrote:
> Le Mon, 08 Aug 2005 16:46:15 +0200
> Zorro <zorro270@yahoo.fr> a écrit:
> 
> I would put it in that order:
> 
> > - Someone does he work on the binutils?
> 
> Maybe a simple bug in relocation stuff, or something binutils
> maintainers did not bother to test, as main targets don't use a.out
> format.
> 

Okay, someone needs to work on this who isn't me ;)

> > - Someone does he work on a decent GCC port ( with working C++
> > compiler)?
> 
> First, we could run the 'make bootstrap' and the various g++ testsuite
> that comes with gcc to check what is broken or not (big hard disk space
> needed, and cpu hours). I think we should use a real atari for this,
> because an emulator could have a cpu/fpu emulation bug.
> 

With sparemint binutils and other packages, I've attempted to compile
gcc 3.3.3 and gcc3.3.6 using the patches on this page: 

http://membres.lycos.fr/pmandin/?page=patch-utils

I use configure string like ../configure --target=m68k-atari-mint (for
cross) or ../configure just for real atari.  And then make... not make
bootstrap..  Both jobs produce a working gcc, one a cross compiler, one
native, both produce a g++ that can compile until you link in iostream
at which point it gives a not found symbol relating to ctype/locale's.
The error was somewhat indecypherable.

Using the cross directions I found here:

http://membres.lycos.fr/pmandin/index.php?page=howto-cross333

I got further but IIRC I got hung up on "compile gcc for mint".  I
believe it bombed not finding certain libs.

At no point have I been able to produce a g++ compiler that produces
even broken code.  It just won't work at all.  I notice it bothers to
compiler gcj, f77 and others.  I wonder if those other compilers work.

Patrice, do you have a good how-to guide for using the test-suites.  I
found differing information, including one thing that said if you don't
have expect working properly (mine complains about not being able to
open a file handle) then there's no point in running hte test suite.

http://gcc.gnu.org/install/test.html

If you look, it says Second, you must have the testing tools installed.
This includes DejaGnu 1.4.4 and later, Tcl, and Expect; the DejaGnu site
has links to these.

Another page said you can test expect by issuing expect -c "spawn ls".
On my linux box that returns "spawn ls", but on my atari box it says it
couldn't open a file handle or too many open files or something very
similar.  But I just found this page which goes into the test suite
process a bit more so I should be able to work something out.

It's a shame it takes so long to get this stuff compiled.  You can only
test one fix per day ;)

> > - Someone does he work on the shareable libraries?
> 
> Maybe it should be possible to load/relocate .a library files (guido,
> frank?). The problem is that .a files don't have versioning (i.e. like
> so library name on linux).
> 

i like the relink method for that.  Otherwise we should use the
versioned .so system and elf I guess?  If it's possible that is.  We
should establish how important it is that gcc/binutils produce tos
compatible binaries... Maybe for most things it won't but it can be an
option?  Not sure.

> > - Someone does he work on the virtual memory support?
> 
> The problem with sharing libraries, is that once a shared lib is
> loaded/relocated, all program that use it must access it through the
> same virtual address. Or the library should be made position
> independant.