That thread may be helpful, you're having similar problems, using g++, you get into name mangling issues. I also think since you're copying libs about, something strange happened when you installed a compiler/library. The correct symlinks to libblah.so.x are setup if things are installed correctly, or your ld.so.conf is not updated properly.
PM_Move is C code, so compiling with g++, you get a mangled name, and the engine won't find it.
At 05:00 PM 6/20/2003 +0200, you wrote:
mmh :( Doesn't work either... HLDS asks for : "VecBModelOrigin__FP9entvars_s".
Please !! Why do I have so many problems with linux :p ?
Cortex.
D. Hofer wrote: > For me it works only when i compile it with gcc and link it with > g++... so > set gcc as the compiler, run the makefile then change the compiler to > g++ (in the makefile) and run it again. > > cya Spin > > On Fri, 20 Jun 2003 15:05:10 +0200, Cortex <[EMAIL PROTECTED]> wrote: > >> Hi, >> >> The solution of Botman didn't work (-lstdc++). >> >> I tried the brut way... I have copied the libstdc++[bla].so.2 to my >> /lib directory, and now, hlds finds it. >> >> However, now, it doesn't find HL SDK symbols :( AAAARGGG >> >> If I compile with g++, it doesn't find "PM_Move". >> If I compile with egcc, it doesn't find BModelSize (or something like >> that, >> with a horrible mangled name). HLDS doesn't seem to find the mangled >> name... >> Have I to change the mangling name version of the compilator ? >> >> (Rest of the answer below). >> >> Florian Zschocke wrote: >>>> I think my problem comes from the fact I use _snprintf and some >>>> STL... >>> >>> What is _snprintf? Usually that _something is M$ stuff (like >>> _strnicmp(). God knows why they have to prefix them with an >>> underscore). Using STL should be no problem, we use deques from the >>> STL in Admin Mod >>> and can link with libstd++ fine. >> >> _snprintf is a function I used to remplace ALL the sprintf in the >> SDK... >> Indeed, I had a memory problem and thought it was a buffer overrun >> caused >> by >> a too long sprintf. It didn't come from sprintf, but I let the >> _snprintf. >> >> But now, this problem is resolved if I place the libstdc++ in /lib. >> >>>> When >>>> I put the "-static" option instead of "-shared" and when I compile >>>> with egcc, it doesn't find these symbols... >>> >>> Uhm, you don't want to use -static. YOu want to produce a dynamic >>> shared object, a .so, so you will need to link with -shared which >>> tell the >>> linker that you want a DSO created. >> >> OK. >> >>>> So, how could I link statically to libstdc++ so that the .so >>>> "contains" the libstdc++[bla].so ? >>> >>> You cannot. The libstdc++[bla].so is just that, a DSO. You cannot >>> link statically against a DSO. If you want to link statically >>> against a >>> library you need to use the static version of the library, the >>> archive. >>> You need to link against libstdc++[bla].a <-- >> >> OK, I think I'll let the libstdc++ thing, and distribute >> libstdc++[Bla].so.2 >> with my mod... Crappy, but if it solves the pb, it's good ;) >> >> Thx for your helps >> >> Cortex. >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list >> archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> >> > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list > archives, please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
