[voogru]

Hi,

I've been recently trying to compile my code for Linux and I'm running into some problems.

First of all, the code compiles fine & dandy, the trouble I'm having is related to the linking.

Most problems I have had in the past with linux have came down to the linking, where I would compile a binary one one box, it would work on that box, and fail miserably once it was moved to another box, and I learned to use "ldd" to check to see if bad stuff will happen.

I'm using the basic makefile for a sourcemm plugin, which is slightly modified, but generally identicle:

#(C)2004-2006 SourceMM Development Team
# Makefile written by David "BAILOPAN" Anderson

HL2SDK = ../Source
SMM_ROOT = ..
SRCDS = ../../srcds_l


### EDIT BELOW FOR OTHER PROJECTS ###

OPT_FLAGS = -O3 -funroll-loops -s -pipe
GCC4_FLAGS = -fvisibility=hidden -fvisibility-inlines-hidden
DEBUG_FLAGS = -g -ggdb3
CPP = gcc
BINARY = FortressAdmin_i486.so

OBJECTS = bitbuf.cpp\
CAdminCommands.cpp\
CEntity.cpp\
CMySQL.cpp\
CPlayer.cpp\
CServerData.cpp\
CUsers.cpp\
CUtil.cpp\
cvars.cpp\
CWeapon.cpp\
EntityList.cpp\
entitylist_base.cpp\
EventHook.cpp\
IceKey.cpp\
MessageHook.cpp\
ORecipientFilter.cpp\
VFuncs.cpp\
WeaponMod.cpp\
CThreads.cpp\
FortressAdmin.cpp

HL2PUB = $(HL2SDK)/public
HL2LIB = $(HL2SDK)/linux_sdk

LINK = $(HL2LIB)/tier1_i486.a vstdlib_i486.so tier0_i486.so -static-libgcc

INCLUDE = -I. -I.. \
-I$(HL2PUB) \
-I$(HL2PUB)/dlls \
-I$(HL2PUB)/engine \
-I$(HL2PUB)/tier0 \
-I$(HL2PUB)/tier1 \
-I$(HL2PUB)/vstdlib \
-I$(HL2SDK)/dlls \
-I$(HL2SDK)/game_shared \
-I$(HL2SDK)/tier1 \
-I$(SMM_ROOT) \
-I$(SMM_ROOT)/sourcehook \
-I$(SMM_ROOT)/sourcemm \
-I ./MySQL

ifeq "$(DEBUG)" "true"
	BIN_DIR = Debug
	CFLAGS = $(DEBUG_FLAGS)
else
	BIN_DIR = Release
	CFLAGS = $(OPT_FLAGS)
endif

GCC_VERSION := $(shell $(CPP) -dumpversion >&1 | cut -b1)

CFLAGS += -D_LINUX -DNDEBUG -Dstricmp=strcasecmp -D_stricmp=strcasecmp -D_strnicmp=strncasecmp -Dstrnicmp=strncasecmp -D_snprintf=snprintf -D_vsnprintf=vsnprintf -D_alloca=alloca -Dstrcmpi=strcasecmp -Wall -w -Wno-non-virtual-dtor -fPIC -fno-exceptions -msse -msse2

ifeq "$(GCC_VERSION)" "4"
	CFLAGS += $(GCC4_FLAGS)
endif

OBJ_LINUX := $(OBJECTS:%.cpp=$(BIN_DIR)/%.o)

$(BIN_DIR)/%.o: %.cpp
	$(CPP) $(INCLUDE) $(CFLAGS) -o $@ -c $<
all:
	mkdir -p $(BIN_DIR)
	ln -sf $(SRCDS)/bin/vstdlib_i486.so vstdlib_i486.so
	ln -sf $(SRCDS)/bin/tier0_i486.so tier0_i486.so
	$(MAKE) sourcemm
	rm -rf $(BINARY)
	ln -sf $(BIN_DIR)/$(BINARY) $(BINARY)

sourcemm: $(OBJ_LINUX)
	$(CPP) $(INCLUDE) $(CFLAGS) $(OBJ_LINUX) $(LINK) -shared -ldl -lm -o$(BIN_DIR)/$(BINARY)

debug:	
	$(MAKE) all DEBUG=true

default: all

clean:
	rm -rf Release/*.o
	rm -rf Release/$(BINARY)
	rm -rf Debug/*.o
	rm -rf Debug/$(BINARY)

Once it's compiled, I perform an ldd on the binary and I'm greeted with this:

linux-gate.so.1 =>  (0x0065a000)
vstdlib_i486.so => not found
tier0_i486.so => not found
libdl.so.2 => /lib/libdl.so.2 (0x00789000)
libm.so.6 => /lib/libm.so.6 (0x0022b000)
libc.so.6 => /lib/libc.so.6 (0x00254000)
/lib/ld-linux.so.2 (0x80000000)

All of the paths to the SDK, srcds are of course, correct.

This is on a linux box with Federa Core 7, and some variation of GCC 4 (thinking GCC4.1 but could be mistaken)
Obviously, I'm still doing something wrong, any ideas what it could be?

[BAILOPAN]

That actually looks fine, if you want it to ldd correctly then those two binaries have to be in your LD_LIBRARY_PATH environment variable.

Since the makefile symlinks those two files you can just do:

export LD_LIBRARY_PATH=".:bin:$LD_LIBRARY_PATH"

And ldd should show them as available... though, these days I tend to also pass the -d -r flags because I have a bad habit of forgetting to add new files to the Makefile.

[voogru]

Originally Posted by BAILOPAN That actually looks fine, if you want it to ldd correctly then those two binaries have to be in your LD_LIBRARY_PATH environment variable. Since the makefile symlinks those two files you can just do: export LD_LIBRARY_PATH=".:bin:$LD_LIBRARY_PATH" And ldd should show them as available... though, these days I tend to also pass the -d -r flags because I have a bad habit of forgetting to add new files to the Makefile.

What exactly does that command do?

If I do that, and move the binary to another box, it should work as well right? (Work in SRCDS), or would that command need to be run on every box?

Thanks!

Update: I went ahead and did this and it solved the problem... with my binary, now I'm trying to start the server with just metamod and it's instantly segfaulting, perfoming an ldd on the linux metamod binary stated that the vstdlib_i486.so and tier0_i486.so were not found.

Then I discovered moving my binary from where it was compiled to where it's supposed to be installed for srcds produced the same result where performing an ldd on my own binary will tell me it's missing stuff

[BAILOPAN]

Hrm, if it segfaulted the binary probably loaded fine (except, then crashed). Linux linking is weird. srcds_run modifies LD_LIBRARY_PATH before loading srcds, so as long as you're not linking to those libraries without any extra path information (i.e. the path is relative to . or bin instead of hard coded), they'll load on any machine.

That's similar to vstdlib.lib linking to vstdlib.dll on Windows, that link is resolved at run-time once the srcds.exe process is loaded and Windows knows which paths to search.

(fyi LD_LIBRARY_PATH is the search paths for .so files)

I would just compile a debug build & fire up gdb to see what's going wrong...

export LD_LIBRARY_PATH=".:bin:$LD_LIBRARY_PATH"
gdb srcds_i486
run
bt

[voogru]

I figured it out.

I'm just a nubtard. The mod I was loading didnt have it's own server.so.

Doh.

Once I got that resolved, I'm just working on the expected missing exports (cause I didnt link mysql just yet).

I did get an interesting error though, undefined export __cxa_guard_release... whatever that is.

[BAILOPAN]

That comes from using some C++ features (sometimes) and not linking to libstdc++ (which is usually trouble anyway).

It's safe to do something hacky like:

void __cxa_guard_release() { }

Just to make the linker completely happy, if needed.

[voogru]

I managed to get it all working, the server runs fine & dandy, but it appears that there is a segfault when I shut down the server. I've compiled a debug version, using gdb and running the server within gdb, however, the backtrace doesnt seem to be giving me anything useful.

When I unload my plugin manually, nothing bad happens. No segfaults, nothing. If I shutdown the server after unloading my plugin, I recieve a segfault. Backtrace gives me an address and a ???, is there anyway I can get it to give me some more useful information?

It only segfaults when I shut it down if I load my plugin. So, probably just me being a nub tard, but I want to pry more informaton out of gdb to figure it out, cause right now it's not doing much for me.

[BAILOPAN]

Sounds like you're not releasing something, like a hook or event listener. MM:S is pretty good about cleaning up stuff related to MM:S (though SourceHook requires that hooks be removed while pointers are still valid). But HL2 is not, so calls to things like IGameEventManager2::AddEventListener need to be paired with removal calls.

[voogru]

Originally Posted by BAILOPAN Sounds like you're not releasing something, like a hook or event listener. MM:S is pretty good about cleaning up stuff related to MM:S (though SourceHook requires that hooks be removed while pointers are still valid). But HL2 is not, so calls to things like IGameEventManager2::AddEventListener need to be paired with removal calls.

If that was the case, wouldnt it do it in windows as well?

[BAILOPAN]

It could be that on Windows it's just corrupting memory silently whereas on Linux it decided to crash. Or some sort of order thing in the tear-down process.