Question1:
Why does "#ifdef cpui8086" work on Windows and not on Linux (on the same computer, with the same CPU)? Does anyone know a documentation about the definition of "cpui8086" (and the other possible conditionals) in fpc.cfg?
Why does "#ifdef cpui8086" work on Windows and not on Linux (on the same computer, with the same CPU)? Does anyone know a documentation about the definition of "cpui8086" (and the other possible conditionals) in fpc.cfg?I am unable to answer the first part of your question simply because afaik there is no documentation on that particular define (other then the sources of the compiler itself).
Hello TRon, thank you for the documentation links.You;re welcome, even though lucamar was first because i'm such a slow typer :-)
But I don't understand what your infos about defines (-d) have to do with my linker problem only for 64-bit programs (for 32-bit it works).Uhm... is my eyeside perhaps bad ?
Why does "#ifdef cpui8086" work on Windows and not on Linux (on the same computer, with the same CPU)? Does anyone know a documentation about the definition of "cpui8086" (and the other possible conditionals) in fpc.cfg?Nah... i must be imagining things ;-)
I started FPC on Linux with -va or -vd and got a lot of output, but don't know what to find there.It is about the conditionals. They get initialised at the beginning of that output, and in case the commandline options or source-code affecting them is in effect, you can see where exactly that happens in the code/handling by the compiler (and or if such define influences other defines).
So no defines (-d) are involved.It is more a general remark on how you can approach something like this. Do you (always) know what the cat dragged in ? :-) I for sure not (and i am to lazy to delve into each and every component/units source-code in order to see what goes around in there.
But ... I'm not very sure but IIRC some targets don't permit smart-linking along with debugging info, so it's one or the other for them. What I don't remember is if *nix x86_64 is one of those :-[At least the rtl should have been compiled with smartlinking turned on, else there is no no joy to begin with (unless that has changed somwhere along the line)
At least the rtl should have been compiled with smartlinking turned on, else there is no no joy to begin with (unless that has changed somwhere along the line)
Why does "#ifdef cpui8086" work on Windows and not on Linux (on the same computer, with the same CPU)? Does anyone know a documentation about the definition of "cpui8086" (and the other possible conditionals) in fpc.cfg?I am unable to answer the first part of your question simply because afaik there is no documentation on that particular define (other then the sources of the compiler itself).
For the second part:
https://www.freepascal.org/docs-html/prog/progap7.html
CPUI8086 indicates a 16-bit x86 target (i8086)
Question1:
Why does "#ifdef cpui8086" work on Windows and not on Linux (on the same computer, with the same CPU)? Does anyone know a documentation about the definition of "cpui8086" (and the other possible conditionals) in fpc.cfg?
Problem2 + Question2:
First I thought, my problem was solved. But when I compiled my program via Lazarus, I saw:
- on Windows => unused procs were excluded (only 32 bit tested)
- on Linux (compile as 32-bit) => unused procs were excluded
- on Linux (compile as 64-bit) => unused procs were not excluded
After spending again more time I found out, that Lazarus sets compiler options -g and -gl which mean:
-g = Generate debug information (default format for target)
-gl = Use line info unit (show more info with backtraces)
And when you compile a 32-bit program with -g and/or -gl => unused procs are excluded.
And when you compile a 64-bit program with -g and/or -gl => unused procs are not excluded.
Question2:
Why are unused procs not excluded with compiler options -g and/or -gl on 64-bit, while they are excluded on 32-bit? Is this "impossible"? What must I do, that unused procs are excluded with compiler options -g and/or -gl on 64-bit too? (I'm not familiar with the linker and still a beginner on Linux).
What happens if you explicitely do:I tried both, but unfortunately it made no difference: in 32-bit unused procs are excluded, in 64-bit they are not.and
/opt/lazarus_206/fpc/bin/x86_64-linux/fpc.sh -B -CX -XX -g demo1.pas
/opt/lazarus_206/fpc/bin/x86_64-linux/fpc.sh -B -CX -XX -g -Pi386 demo1.pas
Inside the configuration file you can check for any define that the compiler either defines internally (e.g. the processor or the target OS) or that was passed on the command line using -d (e.g. RELEASE and DEBUG are two examples).Thank you PascalDragon for that valuable additional information. I did not know this.
...
There are two points involved: first Windows uses (by default) the internal linker, while Linux always uses ld. Also 32-bit uses a different debug format (Stabs) than 64-bit (DWARF).
Would you please test the following points:
- Windows 32-bit with -glw (which will select DWARF)
- Windows 32-bit with -Xe (which will use ld instead of the internal linker)
- Windows 64-bit (both with and without -Xe)
- Linux 32-bit with -glw
- enable -CX -XX
So from my understanding:
- Windows 32-bit with internal linker excludes unused procs even with DWARF
- Windows 32-bit with linker "ld" does not exclude unused procs
- Linux 32-bit with DWARF does not exclude unused procs
Does that mean, that smartlinking with debug infos enabled is impossible on Linux 64-bit?
Possibly, yes. I'll have to take a look myself, maybe I'll find the time for this today evening, but I don't know yet.
@TRon: we have misunderstood each other. You wrote "For the second part:" and then talked about defines. I had thought, you mean my "Question2". Now I know, what you meant. Sorry for confusion.I apologise in return for not having articulated that enough, causing the misunderstanding.
So from my understanding:
- Windows 32-bit with internal linker excludes unused procs even with DWARF
- Windows 32-bit with linker "ld" does not exclude unused procs
- Linux 32-bit with DWARF does not exclude unused procs
Does that mean, that smartlinking with debug infos enabled is impossible on Linux 64-bit?
Possibly, yes. I'll have to take a look myself, maybe I'll find the time for this today evening, but I don't know yet.
// linker specidic:
If the options are really omitted or error, check if you are not using the gold linker as default. This works but currently only for the llvm back-end. (this is by trial and error!, be aware it can be something else..)
I write this because you state you have exanined that man, so it should accept these options. The gold linker has fewer options.
// fpc specific:
If you want to compile as inefficient as possible, use fpc -O-. This should prevent FPC's optimizing stages from removing information before the link stage.
// fpc specific:
If you want to compile as inefficient as possible, use fpc -O-. This should prevent FPC's optimizing stages from removing information before the link stage.
3 month ago you friendly offered that you could find out, if smartlinking with debug infos enabled is possible or impossible on Linux 64-bit (please see reply #11).
Is this work as should be with new FPC version?I did not plan to switch to FPC 3.2.0 in the next future *if there is no concrete need*.
3 month ago you friendly offered that you could find out, if smartlinking with debug infos enabled is possible or impossible on Linux 64-bit (please see your reply #11).