Fpc got undefined reference error when cross compile.

[sainimu78]

I'm ussing the board s5p4418.

My fpc was built by cmd

Code: Pascal  [Select][+][-]

1. sudo make crossinstall CPU_TARGET=arm OS_TARGET=linux INSTALL_PREFIX=/usr

The vender provides me a toolchain its binaries named with "arm-cortex_a9-linux-gnueabi-" profix
I got errors while linking when I built a new Application project using gtk2 LCL widgetset.
The linking warnings and errors are:

Code: Pascal  [Select][+][-]

1. Compile package FCL 1.0.1: Success
2. Compile package LazUtils 1.0: Success
3. Compile package LCLBase 1.6.0.4: Success
4. Compile package LCL 1.6.0.4: Success
5. Compile Project, CPU: arm, Target: /root/tmp/project1: Exit code 256, Errors: 2, Warnings: 4
6. project1.lpr(22,0) Warning: "crti.o" not found, this will probably cause a linking failure
7. project1.lpr(22,0) Warning: "crtbegin.o" not found, this will probably cause a linking failure
8. project1.lpr(22,0) Warning: "crtend.o" not found, this will probably cause a linking failure
9. project1.lpr(22,0) Warning: "crtn.o" not found, this will probably cause a linking failure
10. project1.lpr(22,0) Error: Can't call the linker, switching to external linking
11. project1.lpr(22,0) Error: Error while linking

The ld is wierd of this toolchain, it is not a elf but a script

Code: Pascal  [Select][+][-]

1. #!/bin/sh
2.  
3. call_to=bfd
4.  
5. case "${CTNG_LD_IS}" in
6.     bfd)    call_to=bfd;;
7.     gold)   call_to=gold;;
8. esac
9.  
10. exec "${0}.${call_to}" "$@"
11. exit $?
12.  

I don't know what the script meaning, but when I directly used arm-cortex_a9-linux-gnueabi-ld.bfd, these errors were fixed.
Then other errors came out
The errors are:

Code: Pascal  [Select][+][-]

1. Compile Project, CPU: arm, Target: /root/tmp/project1: Exit code 256, Errors: 1, Warnings: 4
2. project1.lpr(22,0) Warning: "crti.o" not found, this will probably cause a linking failure
3. project1.lpr(22,0) Warning: "crtbegin.o" not found, this will probably cause a linking failure
4. project1.lpr(22,0) Warning: "crtend.o" not found, this will probably cause a linking failure
5. project1.lpr(22,0) Warning: "crtn.o" not found, this will probably cause a linking failure
6. /usr/local/bin/arm-linux-ld: warning: /root/tmp/link.res contains output sections; did you forget -T?
7. /root/libcross/usr/lib//libgdk_pixbuf-2.0.so: undefined reference to `g_type_class_adjust_private_offset'
8. /root/libcross/usr/lib//libatk-1.0.so: undefined reference to `g_type_check_instance_is_fundamentally_a'
9. project1.lpr(22,0) Error: Error while linking
10.  

I totally got no solution to handle this.

So I used the toolchain downloaded by buildroot-2016.05. The binaries of the toolchain is with prefix "arm-none-linux-gnueabi-". I used this toochain to build the new Application project and got no error. I have not tested the built "project1" binary yet, I don't know if it works ok. I'm worry about not using the toolchain the vender provided, I think this will make a bigger problem.

Why it gets different buiding outputs when use arm-cortex_a9-linux-gnueabi or arm-none-linux-gnueabi?
If I'm not using the toolchain the vender provides what will happen?

[Thaddy]

Do a "whereis ld" in a terminal.

Code: [Select]

pi@raspberrypi:~ $ whereis ld
ld: /usr/bin/ld.gold /usr/bin/ld.bfd /usr/bin/ld /usr/share/man/man1/ld.1.gz
Here both ld.gold and ld.bfd are valid linker binaries. You can use one or the other.
You can  change the script the line that reads call_to=bfd into call_to=gold. Try that first.

To set the linker w/o the script:
If it comes back with ld.gold, like /usr/bin/ld.gold set the linker name to /usr/bin/ld.gold. I think it is "-FL/usr/bin/lid.gold" in that case. (Check it)
If it comes back with any other linker name with a dot in it and in one of the bin directories, change as required with the above example.


You may also want to use the Linaro provided toolchain. These are the reference tooling ones for arm. http://www.linaro.org/downloads/

[coliv_aja]

From the messages you can clearly see it can't find the required file (crti.o etc). You may need to specify the location where this  file can be found with -Fl. With Lazarus just open Project Options > Path > Libraries.

[Thaddy]

From the messages you can clearly see it can't find the required file (crti.o etc). You may need to specify the location where this  file can be found with -Fl. With Lazarus just open Project Options > Path > Libraries.

No, that's not always the the case here. Maybe an issue with the correct ABI and many more things. These object files are always there but are ABI dependent.
When the linker issue is finished these will go away. You can also ignore that is most cases. FPC needs to find a valid binary, not the script.
Although the script works in most cases, you may need the another linker. In my case - and here - the default is ld.bfd. so try ld.gold directly.
You may also need to define the proper ABI for your code. See where FPC default to with "FPC -i"

[sainimu78]

Do a "whereis ld" in a terminal.
If it comes back with ld.gold, like /usr/bin/ld.gold set the linker name to /usr/bin/ld.gold. I think it is "-FL/usr/bin/lid.gold" in that case. (Check it)

Thanks, I already did this you know.

[Thaddy]

Then maybe do this first: crossinstall will not build everything:

Code: Pascal  [Select][+][-]

1. sudo make all crossall crossinstall CPU_TARGET=arm OS_TARGET=linux INSTALL_PREFIX=/usr BINUTILSPREFIX=arm-cortex_a9-linux-gnueabi- BINUTILSDIR=<only if they are not on the path set this too>

[sainimu78]

Code: [Select]

[quote author=Thaddy link=topic=33848.msg220220#msg220220 date=1472366173]
make all crossall crossinstall CPU_TARGET=arm OS_TARGET=linux INSTALL_PREFIX=/usr BINUTILSPREFIX=arm-corte...[/quote]
No, it's "can't call" not "can't find". Do you see the waring "warning: /root/tmp/link.res contains output sections; did you forget -T?"
All problems I described are not related with 'linker not found".

[Thaddy]

No, it's "can't call" not "can't find". Do you see the waring "warning: /root/tmp/link.res contains output sections; did you forget -T?"

That one is a linker issue and can be ignored.
In 3.0.x? (I think it is back-ported, not sure)  and trunk this is gone because the way FPC calls the linker has changed. This requires a linker version equal or above 2.26
So the "Did you forget T?" can always be safely ignored. This is documented.

I think it is rather that not everything got built because you used only make crossinstall...

[sainimu78]

I think it is rather that not everything got built because you used only make crossinstall...

You have shown no more special compiler options for me but just some specified paths.
My problem is not related with "linker not found" from the beginning.

[DonAlfredo]

When cross-compiling, you sometimes need to link in extra libraries manually.
E.g. for RPi I need (included at start in the lpr-file):

Code: Pascal  [Select][+][-]

1. {$ifdef Linux}
2.   {$ifdef FPC_CROSSCOMPILING}
3.     {$ifdef CPUARM}
4.     {$linklib GLESv2}
5.     {$endif}
6.     {$linklib libc_nonshared.a}
7.   {$endif}
8. {$endif}

[Thaddy]

When cross-compiling, you sometimes need to link in extra libraries manually.
E.g. for RPi I need (included at start in the lpr-file):

Code: Pascal  [Select][+][-]

1. {$ifdef Linux}
2.   {$ifdef FPC_CROSSCOMPILING}
3.     {$ifdef CPUARM}
4.     {$linklib GLESv2}
5.     {$endif}
6.     {$linklib libc_nonshared.a}
7.   {$endif}
8. {$endif}

That is strange... I don't have to do that. Not from Windows. I have always valid cross crompilers that don't need that at all.
How do you build your RPi cross-compiler? What binutils? This really is never necessary.n (e.g. from some weeks ago (r34006), see http://freepascal.thaddy.com for a working example. Needs linaro binutils installed. zip contains several cross-compilers, including one that targets the RPi. These are from my build farm, not from fpcup
Note you have to copy over the develpment libaries you are using which should include libGLES2.so, that means also those from /opt/vc/lib . No need to explicitly link anything.

The only thing I can think of that causes this is a unit order issue: on the Raspberry Pi OpenGLES doesn't depend on X. See the sources for GLES. I have added a switch there as a patch sometime ago.
In that case, first try the switch else change the unit order so that GLES2 appears before X stuff.

[DonAlfredo]

I started needing these links a year ago. Before that time this was not needed.
Don't know why. It just works and that is ok for me.
Build my own binutil-tools.
For me its acceptable.
And for others too: http://bugs.freepascal.org/view.php?id=30112

The OP-error does look to me like a missing library when linking. Do not yet know what library.

Edit: just saw your edit: will try !!

[Thaddy]

Note that this is the smoking gun:
/usr/local/bin/arm-linux-ld: is the wrong linker!
So my guess about BINUTILSPREFIX=arm-cortex_a9-linux-gnueabi- is correct. You probably also want to set BINUTILSDIR=/the/path/to/the/arm-cortex_a9-linux-gnueabi-/binaries

If you put the binutils in /usr/local/bin (becareful, the binutils often also include short-hand names, like plain ld) then BINUTILSPREFIX=arm-cortex_a9-linux-gnueabi- is enough.

[Thaddy]

Edit: just saw your edit: will try !!

Plz let me know if that was indeed the issue. I got multiple problems in the beginning too, more related to the NOT dependency on X for openvg and OpenGLESv2, hence I submitted the patch.
If it doesn't work, we will have to compare setups.

BTW: I found what OP's issue is. He needs to use BINUTILSPREFIX The output clearly shows he's using the wrong linker, the host os default linker instead of the target platform linker.
I overlooked that. Pretty simple.

He also needs to remember to set

Code: [Select]

ppcrossarm -XParm-cortex_a9-linux-gnueabi- -FD</path/to/the/arm/binutils/ -Tlinux  -Fu/path/to/lib/fpc/3.0.0/arm-linux/units/* project1.lpr when using his crosscompiler.
These options can be included in fpc.cfg for the target.

[DonAlfredo]

@Thaddy.
Tried a lot, to no avail !
One detail: a non-GUI (no Interfaces, no Forms unit) GLES programs compiles flawless.
A standard Lazarus application (with Interfaces,Forms) needs {$linklib GLESv2}
One more detail: my distro (Arch) uses /usr/lib/mesa by default.
But I link my Laz progs with /opt/vc/lib
ps: could not find switch.