FTBFS On FreeBSD

[SlySven]

It is not possible to build this as a Luarock on FreeBSD (I am using 13.2-RELEASE).

I instead cloned the repository but also found that it Failed To Build From Source. I think this is because:

• things are generally located in /usr/local rather than /usr
• the default complier is clang rather than gcc
• FreeBSD supports multiple Lua versions at once - and they are distinguished by a numeric suffix and Lua 5.1 which I am using is not the default

OTOH I did manage to build this library by making the following hacks to the current Makefile:

@@ -1,19 +1,19 @@
 # This Makefile is based on LuaSec's Makefile. Thanks to the LuaSec developers.
-# Inform the location to intall the modules
-LUAPATH  = /usr/share/lua/5.1
-LUACPATH = /usr/lib/lua/5.1
-INCDIR   = -I/usr/include/lua5.1
-LIBDIR   = -L/usr/lib
+# Inform the location of where to install the modules
+LUAPATH  = /usr/local/share/lua/5.1
+LUACPATH = /usr/local/lib/lua/5.1
+INCDIR   = -I/usr/local/include/lua51 -I/usr/local/include
+LIBDIR   = -L/usr/local/lib
 
 # For Mac OS X: set the system version
 MACOSX_VERSION = 10.4
 
 CMOD = yajl.so
 OBJS = lua_yajl.o
 
-LIBS = -lyajl -llua -lm
+LIBS = -lyajl -llua-5.1 -lm
 WARN = -Wall -pedantic
 
 BSD_CFLAGS  = -O2 -fPIC $(WARN) $(INCDIR) $(DEFS)
 BSD_LDFLAGS = -O -shared -fPIC $(LIBDIR)
 
@@ -22,12 +22,12 @@ LNX_LDFLAGS = -O -shared -fPIC $(LIBDIR)
 
 MAC_ENV     = env MACOSX_DEPLOYMENT_TARGET='$(MACVER)'
 MAC_CFLAGS  = -O2 -fPIC -fno-common $(WARN) $(INCDIR) $(DEFS)
 MAC_LDFLAGS = -bundle -undefined dynamic_lookup -fPIC $(LIBDIR)
 
-CC = gcc
-LD = $(MYENV) gcc
+CC = clang
+LD = $(MYENV) clang
 CFLAGS  = $(MYCFLAGS)
 LDFLAGS = $(MYLDFLAGS)
 
 .PHONY: all clean install none linux bsd macosx

[SlySven]

Fortunately the CMake build system does work - unfortunately Luarocks builds use the present Makefile directly....

[brimworks]

Do you have any suggestions on how best to resolve this? Obviously there are a few things in the Makefile which are assumptions that may have to be customized for every OS flavor. Perhaps leaning more into CMake is better?

[SlySven]

TBH I am not a fan of CMake - but that is because I tend to use qmake for the project I code for and Qt's intentions to move from their own qmake to CMake has not impressed me over the past few years. I've gotten use to wangling qmake and since it was their native meta-makefile compiler it was (and still is in my option) better integrated into their own Qt Creator IDE - in comparison CMake seems to be constantly changing and whilst it professes to offer ways to manage those changes it is difficult to comprehend how to get it to do what is wanted especially when a lot of online third party guidance is out of date.

OTOH I don't have any better suggestions. Other than to consider using an environmental value for CC for the compiler/linker to use. Oh and to take a peek and see if the LuaSec project has updated its Makefile! 😆