Peter: I'm guessing the shared library loader is system-agnostic and,
therefore, on a high enough level makes no difference if the shared
library is called a Dynamic Link Library or a Shared Object.
Additionally, they're both synonymous technical terms (and none is
trademarked), so I don't think one should be too pedantic about what
term is used.
Mack: Great to hear it's working. On my machine, I actually softlinked
the files to the build directory and did the same as you. Turns out the
files don't even have to exist in the build directory for the linking to
work, as it's all done at runtime.
~~ Ondra
On 12.10.07 16:51 Uhr, Mack Corl wrote:
--
[ Picked text/plain from multipart/alternative ]
Ondra,
Thanks for pointing me in the right direction! What ended up working for me
is replacing
$(GAME_DIR)/bin/tier0_i486.so $(GAME_DIR)/bin/vstdlib_i486.so
with
-ldl tier0_i486.so vstdlib_i486.so
Just out of curiosity, I went back to check Wunderboy's tutorial and sure
enough he used
those same flags. Apparently I just overlooked that section of the
makefile.
Peter,
Yes, I know that there are no such thing as dlls in linux. I was simply
referring to the line that
is displayed in srcds when you load a game. e.g. Game .dll loaded for
"Counter-Strike Source". :)
On 10/12/07, Ondřej Hošek <[EMAIL PROTECTED]> wrote:
It's probably one of them stupid absolute paths problems.
If your LDFLAGS contain the following:
$(GAME_DIR)/bin/tier0_i486.so $(GAME_DIR)/bin/vstdlib_i486.so
Replace it as follows:
-L$(GAME_DIR)/bin -ltier0_i486 -lstdlib_i486
I've had Source crashing on me for this. Try it and tell me if it helped.
~~ Ondra
On 12.10.07 5:25 Uhr, Mack Corl wrote:
--
[ Picked text/plain from multipart/alternative ]
Hello all,
I'm having an odd problem getting my linux binary running. Essentially,
when I try to init the server it loads the wrong dll:
[EMAIL PROTECTED] cspro-1]$ ./srcds_run -game cspromod -console
Auto detecting CPU
...
Game.dll loaded for "Counter-Strike: Source"
Clearly, this isn't right. If you attempt to change the map to, say,
csp_micro, the server throws several errors about not being able to find
CS:S resources. This, coupled with the fact that srcds_run allows you
to
use the "-game cspromod" parameter leads me believe that the it's trying
to
load the proper bin, but can't, and by default it loads the next one
available in gameinfo.txt
What strikes me as odd, though, is that the game loads the proper binary
when I run srcds on the VM that I built the bin on. I figured that had
to
do with lib conflicts, so I built a new VM and followed Wunderboy's
guide
for compiling under FC6 to the letter. (The first VM was running
Kubuntu
Edgy with GCC 3.4.6 and compat libstdc++)
Again, it worked when I ran it on the VM, but not when I put it on the
production server, which is odd, because the production server is
running
Centos 5 (with much newer versions of GCC and GLIBC.)
I've tried lowering the optimization level at compile time and several
other
frivilous settings to no avail.
Has anyone run into this before? Should this be in the coding forum?
Should I have just e-mailed Alfred directly :) ?
Any help would be greatly appreciated.
Thanks,
-Mack
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
