Re: [hlcoders] Linux compilation problem
Thx a lot for the url. Indeed, it solves my problem with PM_Move (and PM_xxx in fact). But now, hlds asks for VecBModelOrigin__FP9entvars_s again :( I've tried to define the mangled function it with extern C (yep, crappy hack :( ), but it didn't find... What's the matter again ? Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == Pat Magnan wrote: http://www.thewavelength.net/forums/index.php?act=STf=13t=8382s=5a32ae437 13bc6b242369bbb911d2af1 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 :( RGGG 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
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 :( RGGG 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
Re: [hlcoders] Linux compilation problem
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 :( RGGG 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
Re: [hlcoders] Linux compilation problem
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 :( RGGG 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
Re: [hlcoders] Linux compilation problem
http://www.thewavelength.net/forums/index.php?act=STf=13t=8382s=5a32ae43713bc6b242369bbb911d2af1 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 :( RGGG 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
[hlcoders] Linux compilation problem
don't feel left out folks, I posted to this list before about it and finally decided that I was wasting people's time. Now, I have a machine dedicated to getting this task done. I found that slackware 7.1 uses egcs1.1.2 and I am ready to try all of this again. To recap on the issues I was having, they were similar to this. * fresh src = compiler errors * src fixed with botman's fixer, = no compiler errors, hl doesn't work with it - complains about not being able to find things * attempts to build egcs 1.1.2 with slackware 9 = waste of time, wont build * revert to slackware 7.1 and use fixed src = makefile has issues? This is where I am at now. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
Florian Zschocke wrote: Cortex wrote: OK. I search for the command to link statically to a particular lib, but I didn't find it. Do you know it ? You can check the Admin Mod Makefile for more info, but in essecne it boilds down to this: STDCPPLIB=/usr/lib/libstdc++-libc6.2-2.a.3 SHLIBLDFLAGS=-shared -nodefaultlibs -lc -lgcc $(TARGET) : $(OBJS) $(CXX) $(CFLAGS) -o $@ $(OBJS) $(STDCPPLIB) $(LDFLAGS) $(SHLIBLDFLAGS) or g++ [other flags...] -o library.so [objects...] /usr/lib/libstdc++-libc6.2-2.a.3 [other libs like -ldl -lm] -shared -nodefaultlibs -lc -lgcc I tried that, but it doesn't work either :( I think my problem comes from the fact I use _snprintf and some STL... When I put the -static option instead of -shared and when I compile with egcc, it doesn't find these symbols... So, how could I link statically to libstdc++ so that the .so contains the libstdc++[bla].so ? Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
I tried that, but it doesn't work either :( I think my problem comes from the fact I use _snprintf and some STL... When I put the -static option instead of -shared and when I compile with egcc, it doesn't find these symbols... So, how could I link statically to libstdc++ so that the .so contains the libstdc++[bla].so ? Try... -lstdc++ ...in your link command line. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
Cortex wrote: I tried that, but it doesn't work either :( Which part of it doesn't work? 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. 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. 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 -- Florian. -- Want to produce professional emails and Usenet postings? http://www.netmeister.org/news/learn2quote.html ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
t 10:37 PM 6/19/2003 +0200, you 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(). Yup, appears to be another Microsoft abomination... it is used only in cl_dll code however, in the default SDK, so the Microsoft version will work, but, if you're using it in your server code at all, then look at extdll.h: #define _vsnprintf(a,b,c,d) vsnprintf(a,b,c,d) And add a similar macro for the mangled version of snprintf ;). The parameter order and types are the same between M$'s docs and the man page, so the preprocessor can do your work for you. M$ likes to try to suggest these are deprecated in favor of CString/MFC crap, ANSI compliant my 0x0A$$.. ;) -- Want to produce professional emails and Usenet postings? http://www.netmeister.org/news/learn2quote.html ___ 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
Re: [hlcoders] Linux compilation problem
Florian Zschocke wrote: Cortex wrote: LoadLibrary failed on /home/cstrike/hlds_l/albator/dlls/hl_alb_i386.so: /home/cstrike/hlds_l/albator/dlls/hl_alb_i386.so: undefined symbol: cerr You need to link against the libstdc++, either statically or dynamically. Run ldd on your DSO to see if it links against it. You probably didn't link with g++ but with gcc. yep, I compiled with egcs... I've tried with g++, and now, I have to test it (in fact, I don't test it, it's an other guy :p). Thx for your help. Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
Florian Zschocke wrote: You need to link against the libstdc++, either statically or dynamically. Run ldd on your DSO to see if it links against it. You probably didn't link with g++ but with gcc. OK, now, I got an other pb :( It doesn't find 'libstdc++-libc6.0-1.so.2'... Indeed, if I run ldd on my .so, it says that this libstdc++ isn't linked to my .so. How can I link it to my .so ? thx :) Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
OK, now, I got an other pb :( It doesn't find 'libstdc++-libc6.0-1.so.2'... Indeed, if I run ldd on my .so, it says that this libstdc++ isn't linked to my .so. How can I link it to my .so ? thx :) You need to modify your LD_LIBRARY_PATH environment variable or make sure the shared library (.so file) is in one of your library directories (/usr/lib, /usr/shlib/, etc.). See the readme file in the Linux dedicated server distribution about how to set up shared libraries correctly for the hlds_l server. Note: It sounds like you just don't have the C++ package installed correctly (did you install the runtime libraries when you installed the compiler, they may be separate packages depending on your Linux distribution). Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
botman wrote: OK, now, I got an other pb :( It doesn't find 'libstdc++-libc6.0-1.so.2'... Indeed, if I run ldd on my .so, it says that this libstdc++ isn't linked to my .so. How can I link it to my .so ? thx :) You need to modify your LD_LIBRARY_PATH environment variable or make sure the shared library (.so file) is in one of your library directories (/usr/lib, /usr/shlib/, etc.). The exact version of the libstdc++ isn't present in my lib directories, it is perhaps the problem. But, anyway, official .so (ricochet, valve, dmc) don't link to libstdc++ (try a ldd on them). However, mine does link to 'libstdc++-libc6.0-1.so.2'. With ldd, it gives me : 'libstdc++-libc6.0-1.so.2' = not found libm.so.6 = /lib/. #and the two other libs classic .so link to# So, I think I should just link the missing libs (statically ?) directly into my .so. See the readme file in the Linux dedicated server distribution about how to set up shared libraries correctly for the hlds_l server. Does the problem really come from this ? The server that helps me to make the tests run successfully other mods like cs or dod. Note: It sounds like you just don't have the C++ package installed correctly (did you install the runtime libraries when you installed the compiler, they may be separate packages depending on your Linux distribution). As the server runs successfully other mods, I'd be suprised the problem comes from configuration. Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
The exact version of the libstdc++ isn't present in my lib directories, it is perhaps the problem. But, anyway, official .so (ricochet, valve, dmc) don't link to libstdc++ (try a ldd on them). However, mine does link to 'libstdc++-libc6.0-1.so.2'. With ldd, it gives me : 'libstdc++-libc6.0-1.so.2' = not found libm.so.6 = /lib/. #and the two other libs classic .so link to# So, I think I should just link the missing libs (statically ?) directly into my .so. I believe the Valve MODs are compiled and linked with 'gcc' and not 'g++'. The g++ compiler is probably where you are getting the standard C++ library (libstdc++) requirement from. Does the problem really come from this ? The server that helps me to make the tests run successfully other mods like cs or dod. No, but it explains how to set up your library path properly so that applications can find libraries that they require. As the server runs successfully other mods, I'd be suprised the problem comes from configuration. Except you are using 'g++' to compile/link and not 'gcc', thus your 'configuration' is different than the Valve MODs. Jeffrey botman Broome ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
botman wrote: I believe the Valve MODs are compiled and linked with 'gcc' and not 'g++'. The g++ compiler is probably where you are getting the standard C++ library (libstdc++) requirement from. If you ling with g++ it will automatically link against the libstdc++ dynamically. If you want to link against it statically, you should use gcc and add the static library explicitely on your commandline. Florian. -- Want to produce professional emails and Usenet postings? http://www.netmeister.org/news/learn2quote.html ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
Florian Zschocke wrote: botman wrote: I believe the Valve MODs are compiled and linked with 'gcc' and not 'g++'. The g++ compiler is probably where you are getting the standard C++ library (libstdc++) requirement from. If you ling with g++ it will automatically link against the libstdc++ dynamically. If you want to link against it statically, you should use gcc and add the static library explicitely on your commandline. OK. I search for the command to link statically to a particular lib, but I didn't find it. Do you know it ? Great thx. Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
It's -l Persuter At 08:54 PM 6/15/2003 +0200, you wrote: Florian Zschocke wrote: botman wrote: I believe the Valve MODs are compiled and linked with 'gcc' and not 'g++'. The g++ compiler is probably where you are getting the standard C++ library (libstdc++) requirement from. If you ling with g++ it will automatically link against the libstdc++ dynamically. If you want to link against it statically, you should use gcc and add the static library explicitely on your commandline. OK. I search for the command to link statically to a particular lib, but I didn't find it. Do you know it ? Great thx. Michaël Cortex Monerau. cort at meloo dot com == C++ power ! == ___ 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
Re: [hlcoders] Linux compilation problem
Cortex wrote: OK. I search for the command to link statically to a particular lib, but I didn't find it. Do you know it ? You can check the Admin Mod Makefile for more info, but in essecne it boilds down to this: STDCPPLIB=/usr/lib/libstdc++-libc6.2-2.a.3 SHLIBLDFLAGS=-shared -nodefaultlibs -lc -lgcc $(TARGET) : $(OBJS) $(CXX) $(CFLAGS) -o $@ $(OBJS) $(STDCPPLIB) $(LDFLAGS) $(SHLIBLDFLAGS) or g++ [other flags...] -o library.so [objects...] /usr/lib/libstdc++-libc6.2-2.a.3 [other libs like -ldl -lm] -shared -nodefaultlibs -lc -lgcc Florian -- Want to produce professional emails and Usenet postings? http://www.netmeister.org/news/learn2quote.html ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Linux compilation problem
Cortex wrote: LoadLibrary failed on /home/cstrike/hlds_l/albator/dlls/hl_alb_i386.so: /home/cstrike/hlds_l/albator/dlls/hl_alb_i386.so: undefined symbol: cerr You need to link against the libstdc++, either statically or dynamically. Run ldd on your DSO to see if it links against it. You probably didn't link with g++ but with gcc. Florian. -- Want to produce professional emails and Usenet postings? http://www.netmeister.org/news/learn2quote.html ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
