Architecture dependancy in mkoctfile

[David Bateman]

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                                dbateman at dbateman.org
35 rue Gambetta                              +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE            +33 6 72 01 06 33 (Mob)