Ok, seems i need to be more clear on some topics, so i write it out
I cannot get a ppc386 from the interweb thing.
As i wrote before. In case you have 3.0.4 compiler installed then the fpc/.../bin directory contains that file for your platform.
So, I don't quite get what you mean by a bootstrap compiler ??
It is a single executable file capable of compiling Pascal sources (provided that you have a linker and assembler installed correctly on your system).
Bootstrap compiler is just _a_ name to specify a specific executable within the Free Pascal eco system, because otherwise we could end up with quite a mess when two persons are talking about "the compiler".
Think about that for a moment and ask yourself what do _you_ mean when you refer to "the compiler".
More on the term bootstrapping can be found
at wikipedia.
Molly, its building fine, there are no errors. Its just its building with things like -dRELEASE and -Xs
Thats building with the 3.0.2 compiler.
add option -va to your make instruction. Don't wait it out but let it run for a minute, then break the build and see in the log what options the build is using.
I have a files of that name in both my functional compile trees. I'm using the 3.0.2 one, if I use the 3.0.4 one, The Makefile spits it out saying I must use 3.0.2
Currently in this discussion there are two methods being advertised to be able to add debug information to your units. Please don't mix them (unless you're absolutely sure what you're doing).
Method 1:
This method is my own, not officially supported, but should work for building rtl and packages units in order to add debug information to them.
You have 3.0.4 compiler installed and do not want to install 3.0.2 compiler, nor do you want to use 3.0.2 compiler to build a _complete_ 3.0.4 compiler.
That is the method i described in my post including batch file which should work for windows.
This is a method seldom used, as most have _a_ previous fpc compiler installed and are therefor able to build their way up along the different fpc releases.
In case with lazarus (and a fresh OS) there is only one compiler installed, so this method might work as a quick fix to add debug information.
Because this method does not build from the root you can get away with using a starting compiler _not_ required to be of version 3.0.2
Method 2:
The official advertised method.
You _must_ use the 3.0.2 compiler to build the (complete) 3.0.4 compiler. If not, then you receive the error that you mentioned.
In order to add debug information to your compiled units you would need to override default build options because by default no debug information is added.
Both described methods have a couple of things in common, as they both use the fpc build eco-system. So you can see many similarities with regards to providing parameters. They are simply the same.
The difference is that for method 1 you instruct the build system to only build RTL and packages. Because in the end that is all that is required in order to add debug/linenumbers attached to your units (and therefor produced executable, when instructed)
Additionally, in method 1 i'm being more explicit because a) you can (hopefully) learn from that b) my batch is a quick mock-up from a larger script that also builds cross-compilers (there you have to be very explicit with providing parameters).
Whatever method you choose, you still have the second part to handle. For method 1 you _must_ integrated those build units into your existing 3.0.4 installation by modifying your fpc.cfg.
For method 2 you have the choice between chosing to integrate the debug compiled units into your exiting installation _or_ decide to have a complete debug installation of 3.0.4 compiler living next to your original 3.0.4 compiler (that has no debug information attached to compiled units).
That choice is yours to make.
Have you noticed how i _don't_ refer to Lazarus whatsoever ? Since your build instructions fail there is no point in getting it to work for lazarus. First let it work for Free Pascal then we can think about getting it fixed for Lazarus. Just wanting to make sure.
I think the compiler is finding another fpc.cfg somewhere, going to have a good search.
fpc -va or add -va to your build options and it is able to tell you where (if any) .cfg is coming from.
I repeat: for a build process, there are also environment variables that are able to override your build parameters.
ne #91 of a 3K line log. They are not being used there, they are just mentioned. But they are there ! Thats way, way before anything appears to look at fpc.cfg which does not happen until about #900 - after all the clean up.
I see that the offending options appear quite early, about line #91 of a 3K line log. They are not being used there, they are just mentioned. But they are there ! Thats way, way before anything appears to look at fpc.cfg which does not happen until about #900 - after all the clean up.
So, where on earth are these options coming from ?
See my earlier answers.
Note however that when you build the complete compiler that it might be perfectly ok for _some_ projects to compile with these options being active. There is nothing wrong with that (and sometimes even necessary).
Having said all that, this does not seem to be leading somewhere.
Hard facts are required. So a dump of environment variables, build-logs, and -va logs from a test-code build.
I would start with the latter. then a dump from your environment and after that build-logs.
PS: keep note though that i do not have any personal experience with compiling/building on a mac so i might be overlooking something (obvious). I'm relying on others for corrections in case they are necessary.