Magik wrote: > I'm one of the developers of Omni-bot (www.omni-bot.com). A side comment. Not having heard of omni-bot I went to that web site and looked for something that would tell me about it. I may be blind but after looking I still don't know what it is. > We recently ported our stuff to Linux and everything works fine so > far. We're using Debian Sarge to compile our stuff. Sounds good. Except for your problem. > Here comes the problem: > It seems there are still a lot of users out there running glibc-2.2 based > systems. It is interesting to hear this information. Because usually we always hear complaints about how the Debian released stable old and outdated. Hearing you say this means that we are not quite as old and outdated as people would have us believe. :-) > As Sarge comes with glibc-2.3 by default they can't run our stuff. Have you considered shipping the shared libraries you need with your binary and encapsulating your binaries with a wrapper to use your private shared libraries? This works well for me for various local tools not shipped as a debian package. > While we're using some stuff that might require gcc-3.x, we don't depend on > glibc-2.3 so what I want to do is to compile against glibc-2.2. I've tried > to find prepared glibc-2.2-dev packages I could use for Sarge on the web but > I couldn't find one so I tried copying stuff over from Woody, which didn't > work out as well. I then tried compiling the glibc-2.2 from the official > source I got me from http://www.gnu.org/software/libc/libc.html but I always > get compilers errors in the linuxthreads package. I think the typical answer will be to compile in a woody chroot. There are several different packages to help such as pbuilder and dchroot. This works quite well for C programs because gcc is very mature and the woody default gcc compiler is sufficient for most tasks. But if you have a C++ program then you are stuck using the woody g++ and that is not sufficient for many modern C++ programs. In any case, if you can compile in woody chroot, or at least have your production build process do so, then you can ship binaries built against the older woody glibc-2.2.5 and that should run on a wide range of systems directly. Personally I recommend an automated build sytsem that builds in the chroot from checked in sources. Then you can develop natively on your machine in sarge but still ship from a pristine build environment based upon older libraries. > So bascially I'm pretty much out of ideas so far. I'd like to use glbc-2.2 > on Sarge and not switch to an older distribution if possible, as Sarge comes > with Subversion and gcc-3.3.5. > > I'd really appreciate any help or ideas. Is a chroot for development acceptable? Is a chroot for a production build process with development in sarge acceptable? Is shipping all shared libs used with a wrapper to use those acceptable? Bob
Attachment:
signature.asc
Description: Digital signature