Hi guys.

It would be nice if you could add a starting compiler to your source packages, this eases up packaging with gentoo alot. this is especially important for the 1.9.x series, which is changed. (the stable release looks kinda freezed until 2.0.0 is released)

daniel

Sources shouldn't contain binaries. Bootstrapping compilers is always a chicken-and-egg story.

Hi all,

In order to get fpc into portage, the gentoo packaging system it would be necessary to make available a bootstrap tar ball (640 KB) with the ppc386 binary and a default fpc.cfg file.

My suggestion would be the same dir as the fpc source tar ball, i.e. ftp://ftp.freepascal.org/mirrors/fpc/beta/source-1.9.8/

Comments? Questions?

Best wishes - Daniel Herzog

(Shamelessly snaffled, defaced, abandond from here: http://www.nl.freepascal.org/lists/fpc-devel/2005-March/004784.html)

:-)

Sources shouldn't contain binaries. Bootstrapping compilers is always a chicken-and-egg story.

I think he means only the cmdline compiler. A fpc.cfg doesn't matter for bootstrap purposes. (and would be location dependant, and thus useless anyway)

This because the main src archive is not OS-ARCH specific.

He's talking about just a compiler binary (which, in combination with the sources, can be used to bootstrap).

Jonas

640 K ? Is that a joke ? The compiler sources alone are more than 2Mb ?

It makes no sense to do this for a distribution.
You can simply use the .tar.gz file and extract that to the needed places.

Michael.

Ah, this makes more sense...

Michael.

Okay. I'll totally rephrase this now:

Gentoo builds (almost) everything from source.
This is done via ebuilds.
There is grap this file:
ftp://ftp.freepascal.org/pub/fpc/beta/source-1.9.8/fpc-1.9.8.source.tar.gz And compile and install it.

To do this, i need a starting compiler, nothing more.

It would be nice to have a starting compiler like here: ftp://ftp.freepascal.org/pub/fpc/beta/source-1.9.8/ppcARCH

And it would also be nice if you only need the version of your source - like 1.9.8 - and can script the location of the starting compiler from that. Like, in my case:
ftp://ftp.freepascal.org/pub/fpc/beta/source-${MY_P}/ppcARCH Which means, the location of the starting compiler should please not change randomly, but change with the versions...like the source tarballs also do.

Another thing needed is, surprise!, that the corresponding starting compiler works, e.g. always is the binary taken from here: ftp://ftp.freepascal.org/pub/fpc/dist/Linux/ARCH/separate/binary.tar But without all the unit's and stuff, which isnt needed to bootstrap...

I hope this clarified things a bit...

Don't expect this directory to exists very long. When the release is made this directory is moved to an other place.

When this directory doesnt exist anymore a new version of the ebuild is released and that's it. Every project from time to time changes it's files...

Thanks. I'll, for now, work around it using the binary.tar. In practise, the only "problem" is the bigger download, and getting the ppc386 out of it...

This was clear from the beginning :)
But thank you for taking the trouble yo elaborate.

We're discussing on the core list how we can accomodate for things like this. We'll send a mail with the outcome.

Michael.

Even better:
One single archive containing all ppc* starting compilers - this way i could also package it quite easily for all arches, and it would easy to script it using "ppc${ARCH}" everywhere...you see?

A sample configuration, or the great (i really like it) samplecfg tool, are needed, to avoid possibly broken/outdated/... /etc/fpc.cfg files

please add this somehow too.

I'm sorry. Forget about it - OPT="-n" solves it...

This is not needed. The top Makefile already sets RELEASE=1 that implicitly uses -n

See fpc/Makefile.fpc, install/fpc.spec or install/debian/rules how to build everything.

Even better: One single archive containing all ppc* starting compilers - this way i could also package it quite easily for all arches, and it would easy to script it using "ppc${ARCH}" everywhere...you see?

I don't see it. Because that package will be huge since you need a ppc for every cpu-os combination.

I had exactly the same situation with fpc for fink and solved it exactly as suggested by Daniel Herzog. I would go for Individual bootstrap tar balls for each arch, because this saves a lot of bandwidth. I called the one for macosx/darwin:
fpc-1.9.8.darwin.bootstrap.tar.gz. maybe it should be fpc-1.9.8.darwin-ppc.bootstrap.tar.gz. But since we do not support darwin-x86, yet, I did not consider the cpu :)
The tar ball includes the bootstrap binary and the default fpc.cfg file. Is debian for linux only? If so, just the combination of linux with every cpu is needed, and not any combination of os and cpu. But even for a case of any os with any cpu, do you really think that case would be to much?
What is your guess about the distribution impact through debian packages. I guess is that it is noticable, what actually have to wait and see the effect of the fink package.

Best wishes

Well...then on per cpu-os combination...for example ppc linux or something - not neccessarily those seldomly used stuff like mips or so...

I want to package for Gentoo, which, for now, supports the following: alpha amd64 arm hppa ia64 mips ppc ppc64 ppc macos s390 sh sparc x86

But the most important ones are x86, ppc and amd64. There even are devs working on *BSD - it works, but they didnt have official releases yet afaik.

So if you just place a ppc386, ppcppc and a ppc??? somewhere that would be perfectly fine. For now i waste your bandwidth by getting the complete binary.tar.

Does the darwin ppcppc binary actually work on linux-ppc?

Dr. Karl-Michael Schindler wrote

Does the darwin ppcppc binary actually work on linux-ppc?

No, you need a different ppcppc for that.

Jonas

Does the darwin ppcppc binary actually work on linux-ppc?

No. - i just tought ppcppc was linux on ppc....well then, replace it with the correct one :-)

$ ./ppcppc
bash: ./ppcppc: cannot execute binary file
$ file ppcppc
ppcppc: Mach-O executable ppc
$ file ppc386
ppc386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped

Daniel Herzog wrote

No. - i just tought ppcppc was linux on ppc....well then, replace it with the correct one :-)

It is also called ppcppc on linux:
$ file /usr/lib/fpc/1.9.4/ppcppc
/usr/lib/fpc/1.9.4/ppcppc: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, stripped

Therefore, you'd have to have something like both ppcppclinux and ppcppcosx for your scheme to work.

johannes

the second part of the filename of the compiler specifies the target cpu (ie what cpu it produces code for)

no information on the system the compiler itself is meant to run on is contained in the file name

All files should have arch+os+version_it_is_meant_to_bootstrap.

Both OS and arch are a bit dangerous, since FPC notation, ppc<x> notation, GNU notation and uname notation might not match.

I think this should be a nice solution:
bootstrap-<arch>-<os>-<the version i can bootstrap with this>.tar.gz

This results in:
bootstrap-386-linux-1.9.8.tar.gz containing a 1.0.10 version binary, for example.

Please note i used "386" for <arch>, not x86, or something. So <arch> is always a valid ppc* ending. This eases up scripting.

In the FPC crosbuild and installation scripts there are some conversions for this, e.g.

# conversion from long to short archname for ppc<x> case $FPCTARGET in
m68k*)

      PPCSUFFIX=68k;;
    sparc*)
      PPCSUFFIX=sparc;;
    i386*)
      PPCSUFFIX=386;;
    powerpc*)
      PPCSUFFIX=ppc;;
    arm*)
      PPCSUFFIX=arm;;
    x86_64*)
      PPCSUFFIX=x64;;
    mips*)
      PPCSUFFIX=mips;;
    ia64*)
      PPCSUFFIX=ia64;;
    alpha*)
      PPCSUFFIX=alpha;;
  esac

See install/ directory.

Currently, the plan is to have somthing like

ppc-<target>-<version>.tar.gz

Where target is <i386-linux> <i386-Win32>
So, the names of the compiler targets.

We must be able to package it as well, in an automatic way. Thus only compiler-generated info is available. (see ppc386 -i)

Michael.