[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Adonthell-devel] PPC/Sparc input problem fixed - & Python dependanc

From: Alexandre Courbot
Subject: Re: [Adonthell-devel] PPC/Sparc input problem fixed - & Python dependancies problem fixed
Date: Fri, 17 Jan 2003 23:44:24 +0100

> On Fri, 17 Jan 2003 22:56:36 +0100 Alexandre Courbot wrote:
> > > Well, this whole thing has finally gotten on my nerves, so I took
> > > the time to track the error down.
> > 
> > Great! I've also tracked down another problem, Python related this
> > time: on my new system the Python binary is linked with libstdc++,
> > which was of course taken in the dependancies and caused problem at
> > link time. A slight change in fixed that. I think we
> > got some error reports abou this from some players.
> Yeah, but that one ran SuSE and link failed because of libstc++
> missing or something like that. I shouldn't think it will cause
> problems if we link to it explicitly. Shouldn't hurt to remove it
> either.
> Which makes me think: new versions of autoconf come with much better
> python support, don't they? Maybe we can remove some of our own Python
> checks in favour of autoconf's. But then again, maybe better not ;).

Maybe. I'd be for it, but I have already enough problems with automake
1.7! ;) Plenty of errors that forced me to get back to 1.6. They could
keep some compatibility at least!

What are the features of new autoconfs? From which versions? I guess it
can only be better than our tests that doesn't work everywhere :)

> > But now that I can compile & install Adonthell again, I can't run
> > it!
> That's SWIG 1.3.17. Others ran into the same problem. I tried it
> myself, with the same result. So I'm back to 1.3.16.
> I'm not sure about what's causing the problem, but it might be the
> -makedefault flag not properly working anyway (which will add a
> default constructor if none are specified). So a workaround would be
> to explicitly add default constructors to classes that haven't them
> yet.

In C++ side you mean? Yeah, that wouldn't hurt anyway - and would only
be nice programming. Not that I want to troll or anything, *ahem* but
it's Joel's classes that cause the problem ;p

Oh, and while I'm at it. Another problem. With 0.4 this time. After
running and configure I end with an incorrect libtool which
doesn't set:

as it should (and is done with 0.3). Therefore I end with link errors as
we had before:

/bin/sh ../libtool --mode=link g++  -g -Wall -fno-exceptions 
-DDATA_DIR="\"/usr/local/share/adonthell\""    -o alextest  main.o
lmap/libmap.a gfx/libgfx.a input/libinput.a python/libpython.a libbase.a
-L/usr/lib -lSDL -lpthread -Wl,-E -L/usr/lib/python2.2/config
-lpython2.2   -ldl -lpthread -lutil -lstdc++-libc6.2-2 -lz../libtool:
line 1: s%^.*/%%: Aucun fichier ou répertoire de ce type../libtool: line
1: -e: command not found../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
mkdir /.libs
mkdir: cannot create directory `/.libs': Permission denied
make[3]: *** [alextest] Erreur 1

Do you remember what you did to fix that? :)

Oh, other questions. I have errors while compiling the tools in 0.3, but
nothing serious - I'll fix it (dlgedit doesn't use std:: everywhere as
it should). Still, I'd like to know which version of GTK you use so I
can use the same for my tools. Are you using 1.2 or 2.0? Why not moving
the new dlgedits to 0.4, since we should concentrate on that now?

See you and thanks,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]