undefined symbol #9
Comments
|
Some of these are probably 68k specific, but since they are just defining
aliases to work around that emutos is compiled with -mleading-underscore
but libgcc is not, it should be okay.
…On Sat, Aug 4, 2018, 12:50 Paul Wratt ***@***.***> wrote:
ok, almost there, now I am getting:
``
Is the following RPi specific or GCC specific:
ELF_LIB_REF(__mulsi3)
ELF_LIB_REF(__divsi3)
ELF_LIB_REF(__modsi3)
ELF_LIB_REF(__udivsi3)
ELF_LIB_REF(__umodsi3)
ELF_LIB_REF(__aeabi_idiv)
ELF_LIB_REF(__aeabi_idivmod)
ELF_LIB_REF(__aeabi_udiv)
ELF_LIB_REF(__aeabi_uidiv)
ELF_LIB_REF(__aeabi_udivmod)
ELF_LIB_REF(__aeabi_uidivmod)
"i" means integer maths here doesn't it? why are they hard coded? how can
these symbols be present in assembled code if they are NOT present in the
libs they reference (libgcc.a in this case).
when I do arm-none-eabi-nm /usr/lib/gcc/arm-none-eabi/4.8/libgcc.a | grep
"__mul" I get:
00000000 T __muldf3
00000000 T __mulsf3
00000000 T __muldi3
00000000 T __mulvsi3
00000000 T __mulvdi3
00000000 T __mulsc3
00000000 T __muldc3
and when I do arm-none-eabi-nm /usr/lib/gcc/arm-none-eabi/4.8/libgcc.a |
grep "_muls" I get:
00000000 T __mulsf3
_mulsc3.o:
00000000 T __mulsc3
00000000 T __gnu_mulsq3
00000000 T __gnu_mulsa3
same with fpu/libgcc.a. by the way on RPi this usually indicates the need
for -lm and a specific -L directory. but I also notice there are no "i"
references there either, except __mulvsi3 & __mulvdi3.
however all the "aeabi"+"idiv" references seem to be present
I will try non-cross with gcc-6.1.0 tomorrow, as I read in a baremetal tut
that you dont *need* arm-none-eabi when compiling on the actual hardware
(just static linking).
actually I just checked 6.1.0 with /usr/local/gcc-6.1.0/bin/gcc-nm-6.1.0
/usr/local/gcc-6.1.0/lib/gcc/arm-linux-gnueabihf/6.1.0/libgcc.a | grep muls
and I get the exact same as above, also with GCC 4.9, so it looks like some
of those symbols are not present on actual Raspbian/Debian for Pi.
I could probably #if defined(RPI) & !defined(QEMU) the actual values in,
presuming this is the right thing to do (I dont have a m68k-atari-mint on
any Raspbian distro to triple check)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#9>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADT4scKSOcvqqbbHuFxdRAboqeYCnyFtks5uNXxjgaJpZM4Vu8vV>
.
|
|
are you sure, because in theory you should also be getting the error too, and ur not (are you?). is it a Intel build thing (vincents cross tools are on ubuntu). Are u using Windows or Linux to do ur builds? |
|
some of them are needed, but I did not have to add any, so this was acceptable: how come you dont get the errors? and how can this be scripted? (the I am not 100% sure, but it is more than likely things will be the same with ANY GCC on actual RPi Raspbian (I will try to grab a latest Raspbian image and maybe GCC 7 or 8 to test next week to confirm). I would be interested to see if its the same for Raspbian x86 as well, it might be an Intel thing. |
|
Looks like your version of ld requiers the target symbols to be known in a PROVIDE or EXTERN directive. |
|
just to confirm, these are still needed when building on RPi Raspbian: |
ok, almost there, now I am getting:
obj/emutospp.ld:127: undefined symbol '__mulsi3' referenced in expressionIn
emutos.ld, is the following RPi specific or cross-GCC specific:why are they hard coded? how can these symbols be present in assembled code if they are NOT present in the libs they reference (libgcc.a in this case).
when I do
arm-none-eabi-nm /usr/lib/gcc/arm-none-eabi/4.8/libgcc.a | grep "__mul"I get:and when I do
arm-none-eabi-nm /usr/lib/gcc/arm-none-eabi/4.8/libgcc.a | grep "_muls"I get:same with
fpu/libgcc.a. by the way on RPi this usually indicates the need for-lmand a specific-Ldirectory. but I also notice there are no "i" references there either, except__mulvsi3&__mulvdi3.however all the "aeabi"+"idiv" references seem to be present
I will try non-cross with gcc-6.1.0 tomorrow, as I read in a baremetal tut that you dont need
arm-none-eabiwhen compiling on the actual hardware (just static linking).actually I just checked 6.1.0 with
/usr/local/gcc-6.1.0/bin/gcc-nm-6.1.0 /usr/local/gcc-6.1.0/lib/gcc/arm-linux-gnueabihf/6.1.0/libgcc.a | grep mulsand I get the exact same as above, also with GCC 4.9, so it looks like some of those symbols are not present on actual Raspbian/Debian for Pi.edit: I just checked a
arm-none-eabi/4.8.3not from the repo, and it is also the same.I could probably
#if defined(RPI) & !defined(QEMU)the actual values in, presuming this is the right thing to do (I dont have am68k-atari-minton any Raspbian distro to triple check)The text was updated successfully, but these errors were encountered: