CODEWITHSUNDEEP
linkerglibcdynamic-linkingundefined-referencefmi
Iniamyen
Iniamyen

Reputation: 3

FMI - C standard library version differences cause linking errors

I have a publicly-available FMU for which I am trying to link the embedded .so file with the rest of my program. (This is contained within the .fmu file if you view as an archive.) During the linking phase I am getting the following undefined reference errors:

RoomHeating_OM_RH.so: undefined reference to '__longjmp_chk@GLIBC_2.11'

RoomHeating_OM_RH.so: undefined reference to '__fread_chk@GLIBC_2.7'

If I look at the content of RoomHeating_OM_RH.so with a tool like nm -a, I see lots of undefined references of this form that aren't causing errors at link time. Here are a couple such lines from the nm -a output:

U __vsnprintf_chk@@GLIBC_2.3.4

U _setjmp@@GLIBC_2.0

However, the ones that are causing errors are differentiated from the rest of them by the fact that they have newer versions of GLIBC in the name. Here's what I have in my /lib dir for the libc library (yes I realize these are old versions, but it's what I am stuck with for now):

/lib/libc-2.5.so

/lib/libc.so.6

So my guess is that I don't have a new enough version of libc to link against. Is it a requirement that the version of libc be exactly what the .so file calls out? Or does it only need to be equal to or newer than the version called out? Furthermore, does the FMI specification even cover this aspect of compatibility? Or does it assume that IF .so files are provided in the FMU that they MUST be compiled using the same or older versions of libraries as will be installed on the target machine?

Upvotes: 0

Views: 472

Answers (1)

Employed Russian
Employed Russian

Reputation: 213526

So my guess is that I don't have a new enough version of libc to link against.

Correct.

Is it a requirement that the version of libc be exactly what the .so file calls out?

No. You need GLIBC-2.11 or newer. See this answer for explanation.

Upvotes: 1

Related Questions