Library reports undefined symbol: clock_gettime while loading

[marcoonroad]

By some reason, and on my machine, the library builds successfully but can't be loaded into many installed Lua/LuaJIT intepreters (the major exception is Lua Torch). Not sure if it is a bug either on Luarocks or on my environment variables. I've tried to clear/reset my environment variables, but it doesn't work as well. Inspecting the compilation process from Luarocks I obtain the following:

gcc -O2 -fPIC -I/usr/local/include -c src/chronos.c -o src/chronos.o
gcc -shared -o chronos.so -L/usr/local/lib src/chronos.o

But, as you already know, the default system libraries are stored under /usr prefix, not /usr/local prefix. My own workaround was to manually compile with (after unpacking the rock/zip code):

gcc -O2 -fPIC -I/usr/include -c src/chronos.c -o src/chronos.o
gcc -shared -o chronos.so -L/usr/lib -lrt src/chronos.o

And then, copy that chronos.so into the respective chronos.so previously installed (into the associated Luarocks' tree for sure), forcing overwriting (indeed). Now it works fine, but I thought that issue could be relevant here, cause other fellows could ran in the same sort of problem.

Perhaps, that kind of problem could be solved using some pkg-config/.configure stuff to automatically detect the dependencies (in the case, the library rt if my mind is still working in such late night). Thanks in advance, guy!

The complete error, although not much helpful, is here:

lua: error loading module 'chronos' from file '/home/troll/.luarocks/lib/lua/5.3/chronos.so':
        /home/troll/.luarocks/lib/lua/5.3/chronos.so: undefined symbol: clock_gettime
stack traceback:
        [C]: in ?
        [C]: in function 'require'
        [C]: in ?

[ldrumm]

On Sun, Aug 13, 2017 at 06:27:08PM -0700, Marco Aurélio wrote: By some reason, and on my machine, the library builds successfully but can't be loaded into many installed Lua/LuaJIT intepreters (the major exception is Lua Torch). Not sure if it is a bug either on Luarocks or on my environment variables. I've tried to clear/reset my environment variables, but it doesn't work as well. Inspecting the compilation process from Luarocks I obtain the following: ```shell gcc -O2 -fPIC -I/usr/local/include -c src/chronos.c -o src/chronos.o gcc -shared -o chronos.so -L/usr/local/lib src/chronos.o ``` But, as you already know, the default system libraries are stored under /usr prefix, not /usr/local prefix. My own workaround was to manually compile with (after unpacking the rock/zip code): ```shell gcc -O2 -fPIC -I/usr/include -c src/chronos.c -o src/chronos.o gcc -shared -o chronos.so -L/usr/lib -lrt src/chronos.o ``` And then, copy that chronos.so into the respective chronos.so previously installed (into the associated Luarocks' tree for sure), forcing overwriting (indeed). Now it works fine, but I thought that issue could be relevant here, cause other fellows could ran in the same sort of problem. Perhaps, that kind of problem could be solved using some pkg-config/.configure stuff to automatically detect the dependencies (in the case, the library rt if my mind is still working in such late night). Thanks in advance, guy! The complete error, although not much helpful, is here: ``` lua: error loading module 'chronos' from file '/home/troll/.luarocks/lib/lua/5.3/chronos.so': /home/troll/.luarocks/lib/lua/5.3/chronos.so: undefined symbol: clock_gettime stack traceback: [C]: in ? [C]: in function 'require' [C]: in ? ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #6

Thanks for the report. I've had a little look, and it seems that the the real culprit here is not include paths and library paths passed to the compiler by `luarocks`, but the lack of the `-lrt` library link switch - as you mention. Regarding the `-L/usr/local/lib` issue, this shouldn't be a problem and is not controlled by the source rockspeck, but by the global luarocks configuration: ``` luarocks --system-config ``` Will refer to a file where [these paths can be configured](https://github.com/luarocks/luarocks/wiki/Config-file-format) For the compiler this extra search path is likely superfluous as a default set of sane system paths will always be searched by the compiler unless `-nostdlib` or `-nodefaultlibs` is used: ``` cc -print-search-dirs install: /usr/lib/gcc/x86_64-linux-gnu/7/ programs: =/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/bin/ libraries: =/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/7/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/7/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/ ``` That said, if someone's using a custom compiler, built with a non-standard search path, they may experience issues, but I think that's beyond the scope of this bug, and what the rockspec should be expected to handle. I'll post a patch for the `-lrt` issue, with a corresponding version bump in a day or two, when I get some downtime.

[marcoonroad]

OK, thank you by this reply! I'm looking forward for that patch!