[voogru]

Originally Posted by 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.

I nailed it.

Apparently, it didnt like the -static keyword infront of the libs for mysql 5.

[voogru]

It appears I have run into a new problem.

I compiled the my code on Fedora 7, when moving it to another distro of linux I'm recieving this when the code is loaded:

Program received signal SIGFPE, Arithmetic exception.
[Switching to Thread -1208011072 (LWP 10850)]
0x009718fc in do_lookup_x () from /lib/ld-linux.so.2
(gdb) bt
#0  0x009718fc in do_lookup_x () from /lib/ld-linux.so.2
#1  0x00971ca2 in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2  0x00973144 in _dl_relocate_object () from /lib/ld-linux.so.2
#3  0x00a8013a in dl_open_worker () from /lib/tls/libc.so.6
#4  0x009754ee in _dl_catch_error () from /lib/ld-linux.so.2
#5  0x00a80b88 in _dl_open () from /lib/tls/libc.so.6
#6  0x00ab1cb8 in dlopen_doit () from /lib/libdl.so.2
#7  0x009754ee in _dl_catch_error () from /lib/ld-linux.so.2
#8  0x00ab22bb in _dlerror_run () from /lib/libdl.so.2
#9  0x00ab1d11 in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2
#10 0x0027fc34 in CreateInterface ()
   from /home/voogru/srcds_l/cstrike/addons/metamod/bin/server_i486.so
#11 0x00280116 in CreateInterface ()
   from /home/voogru/srcds_l/cstrike/addons/metamod/bin/server_i486.so
#12 0x0027a96e in operator new ()
   from /home/voogru/srcds_l/cstrike/addons/metamod/bin/server_i486.so
#13 0x0027af92 in operator new ()
   from /home/voogru/srcds_l/cstrike/addons/metamod/bin/server_i486.so
#14 0x0027d0a4 in CreateInterface ()
   from /home/voogru/srcds_l/cstrike/addons/metamod/bin/server_i486.so
#15 0x0027e0e3 in CreateInterface ()
   from /home/voogru/srcds_l/cstrike/addons/metamod/bin/server_i486.so
#16 0x02e56db4 in SV_InitGameDLL () from bin/engine_i686.so
---Type <return> to continue, or q <return> to quit---
#17 0x02dd9d65 in Host_Init () from bin/engine_i686.so
#18 0x02e7521f in Sys_InitGame () from bin/engine_i686.so
#19 0x02e784ca in CEngine::Load () from bin/engine_i686.so
#20 0x02e7603d in CModAppSystemGroup::Main () from bin/engine_i686.so
#21 0x02f7d823 in CAppSystemGroup::Run () from bin/engine_i686.so
#22 0x02e772ff in CDedicatedServerAPI::ModInit () from bin/engine_i686.so
#23 0x0061e34a in CDedicatedAppSystemGroup::Main () from bin/dedicated_i686.so
#24 0x00655713 in CAppSystemGroup::Run () from bin/dedicated_i686.so
#25 0x00655713 in CAppSystemGroup::Run () from bin/dedicated_i686.so
#26 0x0061e758 in main () from bin/dedicated_i686.so
#27 0x0804909e in main ()

Thinking it was a problem with the makefile, I took the sample_mm plugin and compiled it with the same makefile.

When loading the sample_mm plugin, I recieved the same problem.

So obviously it's something related to that and not my code.

This is the makefile im using for this:

#(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 = -g3 -ggdb3 -O0
CPP = gcc
BINARY = SampleMM_i486.so

OBJECTS = cvars.cpp\
SamplePlugin.cpp

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

LINK = vstdlib_i486.so \
	tier0_i486.so

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 \

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 -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)
	cp -f $(BIN_DIR)/$(BINARY) $(SRCDS)/cstrike/addons/SampleMM/bin/

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)

I'm trying to run the code on
Linux version 2.6.9-55.0.9.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-) #1 SMP Tue Sep 25 02:17:24 EDT 2007

And I'm compiling the code on:

Linux version 2.6.21-1.3194.fc7 ([email protected] m) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Wed May 23 225:01 EDT 2007

[BAILOPAN]

Very strange... what's the output of "ldd -d -r <binary>" ?

Also, you should probably be linking to tier1_i486.a (it must appear before anything else on the link line).

[voogru]

Originally Posted by BAILOPAN Very strange... what's the output of "ldd -d -r <binary>" ? Also, you should probably be linking to tier1_i486.a (it must appear before anything else on the link line).

I do link to that on my actual program, but for troubleshooting purposes I stripped it down to the barebone. Though, for giggles, I added the linking to that to the makefile, but it didn't change anything.

-bash-3.00$ ldd -d -r SampleMM_i486.so
        vstdlib_i486.so => not found
        tier0_i486.so => not found
        libdl.so.2 => /lib/libdl.so.2 (0x0057f000)
        libm.so.6 => /lib/tls/libm.so.6 (0x0024d000)
        libc.so.6 => /lib/tls/libc.so.6 (0x009d9000)
        /lib/ld-linux.so.2 (0x00969000)
/usr/bin/ldd: line 124: 12899 Floating point exceptionLD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"
-bash-3.00$

Even gives me the error in LDD

Same file on the box where it was compiled:

	linux-gate.so.1 =>  (0x00812000)
	vstdlib_i486.so => not found
	tier0_i486.so => not found
	libdl.so.2 => /lib/libdl.so.2 (0x00a42000)
	libm.so.6 => /lib/libm.so.6 (0x00f2b000)
	libc.so.6 => /lib/libc.so.6 (0x00859000)
	/lib/ld-linux.so.2 (0x80000000)

When compared against the metamod binary (on the box where it doesn't work)

-bash-3.00$ ldd -d -r cstrike/addons/metamod/bin/server_i486.so
        vstdlib_i486.so => bin/vstdlib_i486.so (0x0089f000)
        tier0_i486.so => bin/tier0_i486.so (0x008e3000)
        libdl.so.2 => /lib/libdl.so.2 (0x0087f000)
        libm.so.6 => /lib/tls/libm.so.6 (0x008bd000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00acf000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00111000)
        /lib/ld-linux.so.2 (0x00969000)
-bash-3.00$ ldd -d -r cstrike/addons/SampleMM/bin/SampleMM_i486.so
        vstdlib_i486.so => bin/vstdlib_i486.so (0x00a90000)
        tier0_i486.so => bin/tier0_i486.so (0x008b9000)
        libdl.so.2 => /lib/libdl.so.2 (0x00480000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00173000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00690000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x009ce000)
        /lib/ld-linux.so.2 (0x00969000)
/usr/bin/ldd: line 124: 13278 Floating point exceptionLD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= "$@"
-bash-3.00$

I just tried compiling metamod with the default make file and loading it. Same problem.

It works as long as I don't dare move it to another box.

I just cant ever win with linux

[voogru]

I updated GCC to 4.2.1 on my Fedora 7 box, and it seems to have solved this issue.

Wonder what other surprises im in store for now...

[BAILOPAN]

I've seen a lot of weird Linux compiling issues and yours takes the cake. Mind attaching a binary?

EDIT: I didn't see your post, replied without refreshing

I'm surprised HL2SDK builds with gcc-4.2.1, but if it does, and works on other distros, all the best! I've ran into complicated linux compatibility issues before that ended up being caused by a specific compiler or a specific version of libraries. These days I only compile on Debian stable.

[voogru]

Originally Posted by BAILOPAN I've seen a lot of weird Linux compiling issues and yours takes the cake. Mind attaching a binary? EDIT: I didn't see your post, replied without refreshing I'm surprised HL2SDK builds with gcc-4.2.1, but if it does, and works on other distros, all the best! I've ran into complicated linux compatibility issues before that ended up being caused by a specific compiler or a specific version of libraries. These days I only compile on Debian stable.

It seems I have lost the binaries of my code, but I do have the metamod I compiled that gets the same behavior.

I'll note, that metamod does not compile under GCC 4.2.1, nor the HL2SDK it seems.

The stub plugin compiled though, and I had problems compiling my code until I removed #include <string> from my code and it compiles and runs file now.

Update: metamod compiles and runs without #include <string> ... I dont know why but I have a bad feeling about this.

[BAILOPAN]

If you #include <string> you're using STL which requires linking to libstdc++

libstdc++ has all sorts of cross-distro compatibility issues and it's best to stay away from if you intend on distributing binaries. If you explicitly leave libstdc++ out while using gcc (instead of "g++") things can get weird using STL.

I haven't looked at your binary yet but I figured I could post this in the meantime.