Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] AMD 64

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Benoit PAPILLAULT <benoit.papillault AT sourcemage.org>
  • To: Mads Laursen <smgl AT dossen.dk>
  • Cc: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] AMD 64
  • Date: Mon, 20 Sep 2004 15:47:16 +0200

Mads Laursen a écrit :
On 19/09/04 20.36, wandre.l AT free.fr wrote:
[snip]

BUT lots of spells have outdated configures and do not recognize x86_64.
that would mean having to maintain lots of patches, which would be a real
pain in the ass. So we're a bit stuck at the moment.


Messing around with linux on old SGI Indy machines (gentoo, have not
had the time needed to get smgl to run on the Indy) I've come across a
number of packages that did not configure correctly. They complained
about being unable to identify the platform, and the error message
points out the config.guess file as the problem. It seems that this
problem of outdated config.guess is so common that gentoo has a
specific tweak for them (something gnuconfig), which in essence
consists of replacing the config.guess (and maybe one or two other
files) with uptodate versions. Maybe a similar approach could be
adopted (it should not break other architectures). All that would be
needed would be to have a function to copy the updated files (I guess
the one installed by automake (/usr/share/automake-1.9/config.guess)
should do) and call it as the first statement of BUILD for affected
spells.

This of cause depends on the problem being solvable with new
config.guess files, otherwise actual patches might be needed.

/dossen


In fact, the problem is with libtool. Some configure.in script use libtool and libtool scripts does not recognized the target x86_64. A simple "libtoolize --force" can be a solution. However, I played with a number of spells and some problems arise :

jpeg : this package contains a configure script, but not the configure.in or configure.ac, so it cannot be updated.

- some spells used a lot of m4 macros and most files where missing on the machines I was using. (Maybe since those spells were not compiled).

bin86 : this spells use ugly code that needs to be patched to work on x86_64.

and so on ... thus, from all those problems, I think we would need to check each and every spell.... and give up. I will however publish my bi-arch sorcery scripts on my web page.

Benoit PAPILLAULT




Archive powered by MHonArc 2.6.24.

Top of Page