octave-maintainers
[Top][All Lists]
Advanced

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

Re: Architecture dependancy in mkoctfile


From: David Bateman
Subject: Re: Architecture dependancy in mkoctfile
Date: Fri, 28 Nov 2008 23:53:23 +0100
User-agent: Mozilla-Thunderbird 2.0.0.17 (X11/20081018)

Jeroen Kleijer wrote:
Hi all,

Sorry if this is the wrong mailing list to post this to but I'm not
quite sure where to post this (the maintainer of the EPEL octave
packages directed me to you and since it isn't a bug I thought to try
the maintainers)

I recently installed the octave-devel packages through EPEL and got
both the i386 as well as the x86_64 versions installed.
While trying to compile mpitb I kept getting messages telling me that
the CPU architecture was wrong and it took me a while to figure out
that the machine architecture was defined in the file
/usr/bin/mkoctfile-3.0.1. Through some unfortunate luck, the i386
version was installed right after the x86_64 version which overwrote
the _correct_ mkoctfile and replaced it which caused it to try to
compile everything for i386.
Installing both i386 and x86_64 versions, I wouldn't have thought that sensible package managers would make that possible as certain files overwrite each other as you've found out.

I've made some adjustments to mkoctfile to basically check at the
beginning which architecture is in use and set some variables
depending on them and compilation seems to work fine.
I'm not sure this is a great idea as mkoctfile is in fact built with the same flags as the version of Octave it corresponds to. So checking should not be necessary on a properly installed machine. In fact we can't generate a mkoctfile with the multiple flags like you suggest as we can have no idea what the build flags might be for a potential alternative install of Octave as the builder of Octave can hand tune them as they like.

I know this isn't in the form of a patch or anything but could someone
have a look at it whether this is something that can be incorporated
in future versions? (maybe add other architectures?) Or is this
something that should be done by the maintainer of the packages?
Sorry, no can do in this case.. You'll just have to avoid having both versions installed in the same place. You can still get both versions if you really like, but might have to build Octave yourself in this case with the "--prefix" option of the configure script used to place Octave somewhere else than EPFL places it.

Regards
D.


Kind regards,

Jeroen Kleijer


--
David Bateman                                address@hidden
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)



reply via email to

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