On Linux there are binary portability problems linking to libstdc++ either statically or dynamically. It's off-topic to this thread, but:
- dlopen() on a shared library that links to libstdc++ can fail if the host app or system uses an older version of libc (because of PT_TLS references) and does not link to libstdc++ (HLDS, for example). - sharing libstdc++ structures across libraries can get you into ABI trouble! we have caused some accidental crashes in Valve code. it statically embeds some version of libstdc++ from a distro's gcc-3.4. For more information I invite you to read: http://www.trilithium.com/johan/2005/06/static-libstdc/ http://pages.cs.wisc.edu/~psilord/blog/3.html So there are gotchas but they are more salient to us plugin writers than Valve itself, or people that get to distribute host apps. Regards, -- David Anderson http://www.bailopan.net/ On 8/19/09 6:34 PM, Shane Turner wrote: > Saul, > > You're mistaken. The C++ portion of the code base at my current employer > is statically linked. We've been compiling the code that way for close > to a decade. The code itself uses STL, streams, makes heavy use of > templates, etc. We build on Debian and release on RedHat/CentOS and > Solaris (albeit rarely now). > > Shane Turner > > Saul Rennison wrote: >> If you knew anything about C++ you'd understand how unportable STL is >> across various Linux distributions, and how impossible it is to >> statically link it into the code. >> >> Thanks, >> - Saul. >> >> On 18 Aug 2009, at 21:03, Stefan Popp<[email protected]> wrote: >> >>> Thats not right ;) >>> >>> The programming language is the problem in this case. Why should i write >>> my code with functions that shouldnt be used with C++? >>> C++ works with the stdlib, which means streams. Not C stuff. So its >>> finally up to Valve to write programs which follows C++ standards not C. >>> You cant trust your users as programmer. Its up to us, to make the >>> source safe, and if the projecttime needs 2 weeks more, you should spend >>> the time. >>> >>> >>> Ronny Schedel schrieb: >>>> The problem is not the programming language, the problem is that >>>> Valve trust >>>> their game clients too much. >>>> >>>> >>>> >>>>> Well, >>>>> >>>>> Valve should start coding c++ with steams ;) >>>>> Who works with printfs today? >>>>> >>>>> I hope Valve will fix the whole source to prevent overflows. >>>>> C++ is you friend, not old C stuff... >>>>> >>>>> Best regards, >>>>> Stefan Popp >>>>> >>>>> >>>>> Claudio Beretta schrieb: >>>>> >>>>>> Thanks, anyone knows if a workaround is available? >>>>>> >>>>>> BTW: aren't "security researchers" supposed to contact the developers >>>>>> before >>>>>> releasing 0-day exploits?This is the 2nd 0-day exploy from aluigi >>>>>> in a >>>>>> few >>>>>> weeks -.- >>>>>> >>>>>> >>>>>> On Tue, Aug 18, 2009 at 6:44 PM, Morgan Humes<[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> A friend forwarded me this info regarding a vulnerability. I am >>>>>>> unable >>>>>>> to >>>>>>> test this at the moment, but it does look like it is possible. >>>>>>> Thought >>>>>>> I >>>>>>> would get this out to the community before others start using >>>>>>> this to >>>>>>> cause >>>>>>> havoc. >>>>>>> >>>>>>> http://www.vupen.com/english/advisories/2009/2296 >>>>>>> http://aluigi.altervista.org/adv/sourcefs-adv.txt >>>>>>> >>>>>>> Morgan Humes > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
