i’m trying to cross compile an application that uses librobotcontrol
as soon as i add a reference to librobotcontrol.so, the following is spit out
arm-linux-gnueabihf-gcc -L/home/amf/dev/bbblue/blue_sysroot/usr/lib -o "carbot" ./src/carbot.o ./src/gpio.o ./src/params.o -lpthread -lm -lrobotcontrol
/home/amf/dev/bbblue/blue_sysroot/usr/lib/librobotcontrol.so: undefined reference to `fcntl@GLIBC_2.28'
/home/amf/dev/bbblue/blue_sysroot/usr/lib/librobotcontrol.so: undefined reference to `glob@GLIBC_2.27'
/home/amf/dev/bbblue/blue_sysroot/usr/lib/librobotcontrol.so: undefined reference to `pow@GLIBC_2.29'
collect2: error: ld returned 1 exit status
looking at the contents of librobotcontrol
nm -D librobotcontrol.so
most exported (if this is the correct term) functions are GLIBC_2.4
grepping for fcntl, glob, pow are the only ones that are not GLIBC_2.4
ldd (Debian GLIBC 2.31-13+deb11u12) 2.31
bbblue has had apt update, apt upgrade done
librobotcontrol was compiled and installed on the bbblue
the sysroot was updated after any changes to the bbblue
without including the librobotcontrol on the linker command, the project builds without any errors
any thoughts as to what is going on ??
Your error output shows too many glibc variations. I do not think the linker (ldd) is the issue.
It shows glibc 2.7, 2.8, and 2.9.
On one system, this can cause issues if things/files were ported to the system with specified GLIBC versioning that is a bit different.
Seth
P.S. I am not too familiar with sysroot as of now. I keep reading about it but it seems it is just a location for porting specific files. Anyway, I hope you get it dwindled down and figured out. Maybe try to port the library with the same, and only one, GLIBC. glibc versions on one system Linux in google may provide some clues too:
That above command from what I read entails this idea:
g++ is the cpp binary configurator
-o myapp main.o builds the object file into the binary
-Wl is with library and --rpath=/opt/glibc2.7 show the linker where files are located
Wl is again with library and --dynamic-linker=/opt/glibc2.7/ld-linux.so.2 ./myapp links the application to the GLIBC 2.7 versioning…
--rpath and LD_LIBRARY_PATH work well together.
So, for instance:
If you want to link GLIBC 2.7 to to an application, one could export the LD_LIBRARY_PATH to where the files of GLIBC 2.7 are located.
Or…you can place the export line in .bashrc and then run the command source .bashrc.
So, at the end of the .bashrc file on Debian Distros, sometimes I just place these command(s) to source them later when I need to use them:
export PATH=$PATH:/YOUR/LOCATION/TO/THE/FILE/NEEDED and this entails a working GLIBC version(s) but one at a time…
Now, how complicated can it get and how quickly? No clue. I always thought until earlier in the year that using one version is better than having to link everything and roll the dice.
the image on the bbblue is one of beagleboards, the librobotcontrol was built with/on this same image (bbblue). i would have expected the glibc version to be the same throughout librobotcontrol.
as for sysroot, this is just a rsync of all the needed libs/headers and stuff from the bbblue image to cross compile an application against on the host system.
going to try and turn verbose on and see if there is more info.
was not able to cross compile librobotcontrol on the host, so i just built and install on bbblue
trying to get eclipse setup to do cross compiling on the host. a simple hello world works fine, issues show up when trying to cross compile against libraries on the target.
So, I found some files in librobotcontrol that do not make much sense any longer.
/sys/bus/ and etc…
So, when the newer imaging is compiled and used, not the older working imaging, there are some differences in location via some different type of fs used.
I think there has been so many changes in symlinks (hard and soft), that and the other fs used, changes need to be made to make the new 1.0.6 versioning or 1.1.5 versioning or whatever…
I am sure you are aware. There are a few files. Changes should be made to each one if using a beagleboard.org image.
I think at one point, depending on the image, led.c should point to the file located here:
/sys/class/leds/
But that has since changed too. The gpio-led driver is now derived for other use cases.
Blah…I will try later. It may be a good transition to try it again to see how exactly what and where I left off with what commentary I still have on it.
