Compiling and using glibc-2.2 under Debian Sarge

2005-06-26 Thread Magik
Hi.

I'm one of the developers of Omni-bot (www.omni-bot.com). We recently ported
our stuff to Linux and everything works fine so far. We're using Debian
Sarge to compile our stuff.

Here comes the problem:
It seems there are still a lot of users out there running glibc-2.2 based
systems. As Sarge comes with glibc-2.3 by default they can't run our stuff.
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.
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.

Marc aka Magik


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]



RE: Compiling and using glibc-2.2 under Debian Sarge

2005-06-27 Thread Magik
> 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.

It's an AI framework for variuos games/mods. Currently mainly supporting the
Enemy Territory engine but HL2 support is already in the works.

> 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. :-)

Hehe, yea.

> 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.

Don't think that will be an option as we need to be able to ship "inside"
other mods, e.g. for ETF, and it would probalby bloat the whole package
somewhat.

> 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.

Unfortunately, in our main lib we use C++ and not just plain C. That's why I
think the Woody compiler might be somewhat outdated for our purpose. Maybe I
can find a backport or something, tho.
Think I'll try that.

Thx a lot!
Marc aka Magik


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]