Re: [OctDev] bug with optim-1.1.0.tar.gz and mac os 10.7.4

[Olaf Till]

I'd like to re-state the problem first, for those that don't follow
the OF list:


currently (reported for 3.6.2), mkoctfile stores

BLAS_LIBS="-framework vecLib"

on (some?) Mac systems by default and this value is then returned by

'mkoctfile -p BLAS_LIBS'

In some OF packages we rely on this returned value and pass it back to
mkoctfile when building oct-files. Then mkoctfile complaines on these
systems that it does not understand the switch '-framework'. (It was
reported that configuring Octave with --with-blas="-Wl,-framework
-Wl,vecLib" or similar can successfully work around this problem.)

The problem seems to be triggered by the autoconf standard macro
AX_BLAS in m4/ax_blas.m4, which seems to set BLAS_LIBS to "-framework
vecLib" in these cases.

Should mkoctfile be changed to understand -framework and pass it on to
the linker? If yes, should the change be made in such a way that the
-framework switch is only available at the affected systems?

Or, alternatively, should we try to let ax_blas.m4 to be changed to
set BLAS_LIBS to "-Wl,-framework -Wl,vecLib" instead of "-framework
vecLib"? (But why should they do this, since the current version seems
correct. And we probably could not be sure that this change will be
persistent through the next versions.)


On Wed, Jun 06, 2012 at 07:15:57AM -0400, Jordi Gutiérrez Hermoso wrote:
> On 6 June 2012 05:11, Olaf Till <address@hidden> wrote:
> > In this case it would possibly be more suitable to make mkoctfile
> > understand -framework, at least at systems which need it. I think I'll
> > ask that on the Octave maintainers list.
> 
> If you go this way, the problem is deeper than just -framework. It's
> not an easy problem to deal with, because I would like to also accept
> *all* compiler flags, such as -fexceptions and -std=c++0x, but the
> problem here is: if you pass unrecognised flags, do you pass them to
> the preprocessor, the compiler, the assembler or the linker? mkoctfile
> really wraps all of those. You will notice that mkoctfile makes two
> separate calls, one to compile and one to link. And whatever change
> you make, you have to make sure you don't break existing uses of
> mkoctfile that rely on the current buggy behaviour of accepting -W
> flags as warnings, which is a mistake  I made once.
> 
> There's also the issue that we have two mkoctfile programs, one in
> bash and one in C++.

Is mkoctfile.cc only for use on Windows? Then this specific change
with "-framework" probably would not need to go into it.

> I would like to see mkoctfile get fixed so that you and other Apple
> enthusiasts

Sorry, I never used Apple.

> can use it to your liking, but the problem seems difficult
> to solve in general.
> 
> - Jordi G. H.

At the moment, making mkoctfile recognize -framework along with -l, -L
and -Wl, and making it add it to the linker flags (possibly only on
Apple systems), would solve a current problem that makes mkoctfile not
understand a linker flag which it itself returns by 'mkoctfile -p ...'
by default on some systems, a problem which hinders building of some
OF packages on these systems with a default Octave configuration.

Of corse I understand that the problem is more general. Thats not
something I'd like to go into too far now. I didn't suggest to pass on
unrecognized compiler flags. Isn't recognizing one more flag (even if
only passing it to the linker, although it seemingly also could passed
to the compiler) a step in the right direction?

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

signature.asc
Description: Digital signature