Fixed libcurl.so on Linux

[PixelPaladin]

Hello everyone, I just downloaded Cerberus for Linux but applications do not compile because of libcurl.so. However if I change the LDFLAGS in the makefile from:

LDFLAGS=-L../curl/lib/Linux

to:

LDFLAGS=

everything works just fine.

 

[dawlane]

That should be marked as a bug. The use of the -L option should really only be used for looking for static libraries and not shared objects, unless you know what you are doing.

As libcurl is usually a standard package, all that's needed is to install the distributions development package for that library.
Shared libraries should go in those areas as described in Linux-File-System-Hierarchy: That would be in the /usr/lib and /usr/local/lib.

It is possible to distribute a shared library in the applications root directory, but requires the knowledge and use of RPATH and RUNPATH.

 

[JaviCervera]

I also have this problem. Is it going to be addressed on the next release?

Thanks in advance!

 

[Martin]

Yep will fix that. Dawlane as you're quite experienced especially with Linux (where I lack some knowledge) would you be able to take care about the Linux part of Cerberus?

 

[dawlane]

I do have a fair bit of experience with Linux, but I wouldn't say that its extensive and I will help out where I can.

You shouldn't need to include the header files or the -I../curl/include in the makefile. Once you have one of the libcurl development packages installed (Linux Mint/Ubuntu libcurl4-openssl-dev or libcurl4-gnutls-dev the SSL is recommended) the system will find it as long as the package maintainer has done their job properly and you have added #include <curl/curl.h> to the httprequest.cpp. if other include paths are required for other operating systems, then filter with OS pre-processor directives.
off topic
By the way, didn't Mark implement the passing of CFLAGS and LDFLAGS via a couple of MonkeyX directives for GLFW on his last release of the transcc sources? I don't think that the docs were updated. That should be the preferred method of adding additional compiler parameters to a makefile; it should also be possible if I recall to do it for Visual Studio and xcode-build. Hard coding libraries is not a good idea, especially on Linux as not everyone will have the required libraries installed and end users don't like having to install additional libraries for an application if it never uses them.

 

[dawlane]

I've just looked at the transcc sources. He implemented

ccopts+=" "+GetConfigVar( "GLFW_GCC_CC_OPTS" ).Replace( ";"," " )
ldopts+=" "+GetConfigVar( "GLFW_GCC_LD_OPTS" ).Replace( ";"," " )

for GCC, but didn't implement passing LDLIBS or update the Linux makefile.

 

[Martin]

Thanks, hmm I see. Will take a look into that next week when I'm back from vacation. Time for a new release then I guess.

 

[Martin]

So basically, to get this straight. It would be enough to apply that change to the makefile in posting #1? As usually everything is there or can be installed anyway?

 

[dawlane]

So basically, to get this straight. It would be enough to apply that change to the makefile in posting #1?

Yes and no. Think in terms of future expansion and flexibility.

Clone my fork and have a look if you already haven't and take a look at the builder glfw.cxs + transcc.cxs for GCC and both the winnt and linux makefiles. Also check out the httprequest.cxs and httprequest.glfw.cpp.

I've tried to avoid any direct hard coding of paths, link options, apart from where they mattered. Like the central lib directory for Windows stuff. The user controls the build through GLFW_GCC_CC_OPTS, GLFW_GCC_LD_OPTS and GLFW_GCC_LIBS_OPTS.

Here's the Linux make file:

CC=gcc
CFLAGS=

CXX=g++
CXXFLAGS=

CPPFLAGS=$(CCOPTS) \
-Wno-int-to-pointer-cast \
-Wno-free-nonheap-object \
-Wno-unused-result \
-I../glfw3/include \
-I../openal/include \
-I../stb \
-I../glfw3/deps \
-I../glfw3/deps/vulkan \
-D_GLFW_HAS_GLXGETPROCADDRESS \
-pthread

LD=g++
LDFLAGS=$(LDOPTS)
LDLIBS=-lGL -lX11 -lXxf86vm -lXi -lXrandr -lXinerama -lXcursor $(LIBOPTS) -lpthread -ldl

vpath %.c ../glfw3/src
vpath %.c ../stb
vpath %.cpp ..

OBJS0=\
context.o \
init.o \
input.o \
monitor.o \
window.o \
glx_context.o \
x11_init.o \
x11_monitor.o \
x11_window.o \
posix_time.o \
posix_thread.o \
linux_joystick.o \
vulkan.o \
egl_context.o \
osmesa_context.o \
xkb_unicode.o \
stb_vorbis.o \
stb_image.o \
main.o

TMP=build/$(dir $(OUT))

OBJS=$(patsubst %.o,$(TMP)%.o,$(OBJS0))

all : $(OUT)

$(OUT) : $(OBJS)
    $(LD) $(LDFLAGS) -o $@ $(OBJS) $(LDLIBS)

$(TMP)%.o : %.c
    $(CC) $(CFLAGS) $(CPPFLAGS) -c -o $@ $<

$(TMP)%.o : %.cpp
    $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c -o $@ $<

The Windows GCC makefiles are similar.

I will be tackling Visual Studio and Linux shared library copying.

 

[Martin]

Hey dawlane, I integrated your changes. Thanks so much again. Preparing a new release....

 

[dawlane]

Hey dawlane, I integrated your changes. Thanks so much again. Preparing a new release....

You're welcome. Though I have been working on something a little more advanced that gives you more control than the basic stuff. It's related to my idea's with improving GLFW, but requires a few big changes on how projects are built. I'm trying to make it so that there is less messing around with building stuff.

I've been at it most of this week wrapping my head around Xcode project file, xcodebuild, frameworks, the Mach-O format and those wonderful obscure tools and compiler switches that there is little information about.

I did have a bit of fun with getting lib curl to compile. I think that they need to update it a bit, I kept getting warning about gssapi being depreciated.

I've almost got the OS X GLFW stuff sorted, just looking at the best way to get icons images, then it will be back over to Window to deal with Visual Studio and MinGW and last Linux.

Edit: And I almost forgot. The rebuildall.sh script is getting an overhaul so that everything and be built from source on either Linux or OS X.

 

[Martin]

Thanks! I've fixed a clang error in process.cpp for MacOS, which prevented GLFW builds with latest XCode.

But for cserver_macos (I just build it with Ted) I get now

LSOpenURLsWithRole() failed with error -10810 for .... cserver_macos.app when trying to start a HTML5 app.

Seems like kind of an access issue, I already did that chmod +x but with no effect...

 

[dawlane]

Can't get Xcode 9 installed, hardware's too old for it. Best I can get is Xcode 8.2. What's the Xcode project files minimum deployment target set to? For what I under stand the minimum is now 10.9.

 

[Martin]

Yes it's 10.9. That change I made shouldn't influence older versions, take a look at Github.

I still cannot get rid of that stupid libstdc++ warning from clang, as I shall now use libc++ and use a minimum target of 10.9. I have currently no idea how to achieve that but haven't dived that deep into it yet. Do you have an idea?

 

[dawlane]

I have currently no idea how to achieve that but haven't dived that deep into it yet. Do you have an idea?

Not yet but it's one that currently crops up from time to time. See what happens by adding -std=c++11 and -stdlib=libc++

Edit: Did a little digging and the only sure way to get rid of the warning is to rewrite half of what Mark wrote to handle both libstdc++ and libc++.

 

[dawlane]

LSOpenURLsWithRole() failed with error -10810 for .... cserver_macos.app when trying to start a HTML5 app.

Seems like kind of an access issue, I already did that chmod +x but with no effect...

Just though. Could this be a Gatekeeper issue?