Stuck with getting Cuberite to compile on FreeBSD

[DrMasik]

I get next error:

[ 12%] Linking C executable tolua
/usr/bin/ld: cannot find -lltdl
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make[2]: stopped in /store1/minecraft/minecraft-test/cuberite/Release
*** Error code 1

Stop.
make[1]: stopped in /store1/minecraft/minecraft-test/cuberite/Release
*** Error code 1

Stop.
make: stopped in /store1/minecraft/minecraft-test/cuberite/Release

[bearbin]

What shell are you using? The buildserver should build the same, just that it's a script not a live shell session.

[DrMasik]

What shell are you using? The buildserver should build the same, just that it's a script not a live shell session.

I'm using csh.
=============
What I did:
mkdir Release
cd Release
cmake -DCMAKE_BUILD_TYPE=RELEASE ..
make

[worktycho]

Have you installed libltdl?

[DrMasik]

Have you installed libltdl?

Yes.

Code:

pkg version | grep libltdl
libltdl-2.4.6

[worktycho]

Then I'm afraid thats as far as I can help with freebsd, It looks like there might be a problem with the library include path, but I've no idea how freebsd handles that.

[Seadragon91]

Strange. I had the same problem installed libltdl, run make and cuberite then fully compiled.

[DrMasik]

I found solution.
I'm add

Code:

"-L /usr/local/lib"

into next files:

Code:

../Release/lib/tolua++/CMakeFiles/tolua.dir/link.txt
../Release/src/CMakeFiles/MCServer.dir/link.txt

But I get next errors

Code:

Scanning dependencies of target sqlite
[ 13%] Building C object lib/sqlite/CMakeFiles/sqlite.dir/lsqlite3.c.o
[ 13%] Building C object lib/sqlite/CMakeFiles/sqlite.dir/sqlite3.c.o
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:23345:42: error: use of undeclared identifier 'fchmod'
  { "fchmod",       (sqlite3_syscall_ptr)fchmod,     0  },
                                         ^
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:23392:22: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
    for(i=0; i<sizeof(aSyscall)/sizeof(aSyscall[0]); i++){
                     ^~~~~~~~~~
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:23401:22: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
    for(i=0; i<sizeof(aSyscall)/sizeof(aSyscall[0]); i++){
                     ^~~~~~~~~~
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:23428:20: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
  for(i=0; i<sizeof(aSyscall)/sizeof(aSyscall[0]); i++){
                   ^~~~~~~~~~
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:23445:16: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
    for(i=0; i<ArraySize(aSyscall)-1; i++){
               ^~~~~~~~~~~~~~~~~~~
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:8260:38: note: expanded from macro 'ArraySize'
#define ArraySize(X)    ((int)(sizeof(X)/sizeof(X[0])))
                                     ^~~
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:23449:14: error: invalid application of 'sizeof' to an incomplete type 'struct unix_syscall []'
  for(i++; i<ArraySize(aSyscall); i++){
             ^~~~~~~~~~~~~~~~~~~
/store1/minecraft/minecraft-test/cuberite/lib/sqlite/sqlite3.c:8260:38: note: expanded from macro 'ArraySize'
#define ArraySize(X)    ((int)(sizeof(X)/sizeof(X[0])))
                                     ^~~
6 errors generated.
*** Error code 1

Stop.
make[2]: stopped in /store1/minecraft/minecraft-test/cuberite/Release
*** Error code 1

Stop.
make[1]: stopped in /store1/minecraft/minecraft-test/cuberite/Release
*** Error code 1

Stop.
make: stopped in /store1/minecraft/minecraft-test/cuberite/Release

[worktycho]

Looking at the patch linnemannr submitted on github, defining the macro _XOPEN_SOURCE as 600 might help. I can create a patch for Cuberite that handles that and the link error automatically if you're willing to test it.

[sphinxc0re]

@worktycho can't this be handles by a cmake exception instead of applying a patch every time we compile it?