do I need to recompile libc.a?

I get this errors when I compile my lib on jetson

undefined reference to _toupper_tab_' undefined reference to ctype

I googled and this should be part of libc.a and it should come from libc/ctype.h file
I see this is defined in some of the android sources that I came across while searching for answers.

So would I need to recompile the lib on jetson to give me this support?
I already installed gcc 4.9 on jetson because I couldn’t compile the project with v4.8

File ctype.h only provides a prototype. Actual libc.a provides the definition. The error is from link stage not finding the implementation of the declaration. Either your linker was not told which library to use, or the correct library does not have the symbol.

libc itself is a very well known library, and if this is truly where the symbol needs to be, then either your link path is missing or the library is a version mismatch. I am suspicious of whatever triggered the need to upgrade to gcc 4.9. Why was 4.9 needed?

gcc is very intertwined with libc and linker software, and it isn’t practical to port all of libc and binutils on L4T to another version. If you have something which is already compiled (at least in part) against newer versions you’re probably out of luck. Should your software have been built to work with android (your comment above indicates this), then your efforts will probably have to be more clever and customize parts of software you never considered. What was the software originally built for?

gcc4.9 because of this:

the thing is I’m compiling a whole project on jetson. I compiled all static libraries except one. This one was compiled for me with a cross compiler for ARM7 (I’m not allowed to have the source code).

I then compile our API which is a dynamic library. Everything fine up to this point.

In the last stage I’m compiling a sample app that uses our dyn library. And this is where i get the errors to undefined references.

I asked the person that crosscompiled the static library if there are any definitions to the above types. The only explanation I currently have is that this is because they were included in the cross compiled library. But jetson TK1 gcc installation does not have this types defined. So if this is true cross compiling static library without references to those types should fix it. That is if my thinking is correct.

FYI, I’m still wondering about that internal error. That error can still occur because of source code dependent problems when the source code comes from some wildly different environment…it isn’t necessarily the compiler, although it could be. Sadly, that’s one which is hard to pin down.

For all libraries used in your project, especially the one compiled for you, does the “file” command show something like this, and do any vary?

ELF 32-bit LSB  shared object, ARM, EABI5 version 1 (SYSV), dynamically linked

What was the source of your gcc4.9? I always use Linaro tool chains, and default packages on L4T for gcc are Linaro. As the wording suggests, this is a “chain” of files and tools…did you also provide a 4.9 compatible binutils? Was that binutils compatible with 4.9?

don’t know what file command you’re talking about

Literally, “file”:

which file

…this should return “/usr/bin/file”. The argument to “file” would be the full path to any library linked to or embedded in your resulting executable, as well as the executable itself. We’re hunting for mismatched architectures or calling conventions.

Also: If you run “ldd” with your executable as an argument it might offer information on linkage…this fails in cases where the executable is sufficiently broken relative to the host architecture.

But I don’t have an executable. It doesn’t compile because of the error described :)

I checked the cross compiled library and looks like I was right. It contains references to those types that are missing on jetson. So I asked my colleague to recompile it for me without those references in ctype.h and that should solve the issue

Here’s an idea to make it work well. Linkers and compilers tend to read what they find in the files being linked or compiled. If the person doing the compiling does not have a set of files to link and compile against which match your version, it’s always going to be a mess. You can have your colleague compile against a sample rootfs for your L4T version; make sure it has had run on it. Variations of this are possible, I tend to use a loopback mounted copy of the image I flashed with…which in turn has been updated via rsync.