Problem compiling Octave on Mac OS X

[webb.sprague]

I just ALMOST compiled octave on my mac, linking to the Mac Port libraries.
Here is my configure:

./configure --prefix=/usr/local/octave-3.0.5  LDFLAGS=-L/opt/local/lib
CPPFLAGS=-I/opt/local/include

I then ran "make" and it churned away until it exited with the following error:

ld: Undefined symbols:
_METIS_NodeComputeSeparator
_METIS_NodeND
/usr/bin/libtool: internal link edit command failed
make[2]: *** [liboctave.dylib] Error 1
make[1]: *** [liboctave] Error 2
make: *** [all] Error 2

I don't know how to get libtool version information, but it is run as
/usr/bin/libtool, so it is NOT the Mac Ports version (which would be in
/opt/local/...)

Any help would be very much appreciated!
-W

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Ben Abbott]

On May 31, 2009, at 4:59 PM, ws wrote:

> I just ALMOST compiled octave on my mac, linking to the Mac Port  
> libraries.
> Here is my configure:
>
> ./configure --prefix=/usr/local/octave-3.0.5  LDFLAGS=-L/opt/local/lib
> CPPFLAGS=-I/opt/local/include
>
> I then ran "make" and it churned away until it exited with the  
> following error:
>
> ld: Undefined symbols:
> _METIS_NodeComputeSeparator
> _METIS_NodeND
> /usr/bin/libtool: internal link edit command failed
> make[2]: *** [liboctave.dylib] Error 1
> make[1]: *** [liboctave] Error 2
> make: *** [all] Error 2
>
> I don't know how to get libtool version information, but it is run as
> /usr/bin/libtool, so it is NOT the Mac Ports version (which would be  
> in
> /opt/local/...)
>
> Any help would be very much appreciated!
> -W

It appears that MacPorts expects METIS to be included with the install  
of SuiteSparse.

Documentation for SuiteSparese can be found below

        http://www.cise.ufl.edu/research/sparse/SuiteSparse/

I don't believe Octave uses the METIS code. In addition the METIS  
package has a license that is incompatible with Octave's. I recommend  
you build your suitesparse to run without METIS.

Ben


_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Rob Mahurin]

On May 31, 2009, at 7:44 PM, Ben Abbott wrote:

> On May 31, 2009, at 4:59 PM, ws wrote:
>> I just ALMOST compiled octave on my mac, linking to the Mac Port
>> libraries.
>> [...]
>> I then ran "make" and it churned away until it exited with the
>> following error:
>>
>> ld: Undefined symbols:
>> _METIS_NodeComputeSeparator
>> _METIS_NodeND
>> /usr/bin/libtool: internal link edit command failed
>> make[2]: *** [liboctave.dylib] Error 1
>> make[1]: *** [liboctave] Error 2
>> make: *** [all] Error 2
>>
> It appears that MacPorts expects METIS to be included with the install
> of SuiteSparse.
>
> Documentation for SuiteSparese can be found below
>
> http://www.cise.ufl.edu/research/sparse/SuiteSparse/
>
> I don't believe Octave uses the METIS code. In addition the METIS
> package has a license that is incompatible with Octave's. I recommend
> you build your suitesparse to run without METIS.

If you're not planning to redistribute your binary the license  
incompatibility isn't so terrible.  In that case you could "port  
install metis".

Rob

--
Rob Mahurin
Department of Physics and Astronomy
University of Tennessee 865 207 2594
Knoxville, TN 37996 rob@...



_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Rob Mahurin]

On May 31, 2009, at 4:59 PM, ws wrote:
> I just ALMOST compiled octave on my mac, linking to the Mac Port  
> libraries.


Well now I have a similar question.  My missing symbols are

Undefined symbols:
   "_CGDisplayPixelsHigh", referenced from:
       display_info::init()      in display.o
   "_CGDisplayPixelsWide", referenced from:
       display_info::init()      in display.o
   "_CGDisplayBitsPerPixel", referenced from:
       display_info::init()      in display.o
   "_CGMainDisplayID", referenced from:
       display_info::init()      in display.o
   "_CGDisplayScreenSize", referenced from:
       display_info::init()      in display.o
ld: symbol(s) not found

and come when linking liboctinterp.dylib.  Any hint what I'm missing?

This is on an Intel Mac running 10.5, where I haven't compiled Octave  
before.  I don't seem to have the problem on my 10.4 powerbook.  Same  
problem in 3.2.0-rc4 and in the current tip.

Thanks,
Rob

--
Rob Mahurin
Department of Physics and Astronomy
University of Tennessee 865 207 2594
Knoxville, TN 37996 rob@...



_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Ben Abbott]

On Jun 1, 2009, at 2:49 PM, Rob Mahurin wrote:

> On May 31, 2009, at 4:59 PM, ws wrote:
>> I just ALMOST compiled octave on my mac, linking to the Mac Port
>> libraries.
>
>
> Well now I have a similar question.  My missing symbols are
>
> Undefined symbols:
>   "_CGDisplayPixelsHigh", referenced from:
>       display_info::init()      in display.o
>   "_CGDisplayPixelsWide", referenced from:
>       display_info::init()      in display.o
>   "_CGDisplayBitsPerPixel", referenced from:
>       display_info::init()      in display.o
>   "_CGMainDisplayID", referenced from:
>       display_info::init()      in display.o
>   "_CGDisplayScreenSize", referenced from:
>       display_info::init()      in display.o
> ld: symbol(s) not found
>
> and come when linking liboctinterp.dylib.  Any hint what I'm missing?
>
> This is on an Intel Mac running 10.5, where I haven't compiled Octave
> before.  I don't seem to have the problem on my 10.4 powerbook.  Same
> problem in 3.2.0-rc4 and in the current tip.
>
> Thanks,
> Rob

I took a quick glance at the sources. It looks like these are part of  
Apple's  Carbon framework.  Make sure your Xcode is up to date.

Are you really running 10.5.0. I'm running 10.5.7.

Ben
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Bernard Desgraupes-2]

I have been building Octave from the HEAD sources (I mean the latest  
version in the Mercurial repository) recently and I also stumbled into  
this metis issue.
MacPorts uses the following trick to get around this:
post-patch {
     reinplace "s|-lcholmod|-lcholmod -lmetis|g" ${worksrcpath}/
configure
}


In other words they patch the configure script. As a result the  
Makefile contains the following declaration:
CHOLMOD_LIBS = -lcholmod -lmetis

The issue indeed is just that the metis library is not found at link  
time. Adding -lmetis solves the problem. I suggest the macro in the  
configuration phase checking for the presence of CHOLMOD be improved  
and include this -lmetis bit.

cheers

Bernard



Le 1 juin 09 à 01:44, Ben Abbott a écrit :

>
> On May 31, 2009, at 4:59 PM, ws wrote:
>
>> I just ALMOST compiled octave on my mac, linking to the Mac Port
>> libraries.
>> Here is my configure:
>>
>> ./configure --prefix=/usr/local/octave-3.0.5  LDFLAGS=-L/opt/local/
>> lib
>> CPPFLAGS=-I/opt/local/include
>>
>> I then ran "make" and it churned away until it exited with the
>> following error:
>>
>> ld: Undefined symbols:
>> _METIS_NodeComputeSeparator
>> _METIS_NodeND
>> /usr/bin/libtool: internal link edit command failed
>> make[2]: *** [liboctave.dylib] Error 1
>> make[1]: *** [liboctave] Error 2
>> make: *** [all] Error 2
>>
>> I don't know how to get libtool version information, but it is run as
>> /usr/bin/libtool, so it is NOT the Mac Ports version (which would be
>> in
>> /opt/local/...)
>>
>> Any help would be very much appreciated!
>> -W
>
> It appears that MacPorts expects METIS to be included with the install
> of SuiteSparse.
>
> Documentation for SuiteSparese can be found below
>
> http://www.cise.ufl.edu/research/sparse/SuiteSparse/
>
> I don't believe Octave uses the METIS code. In addition the METIS
> package has a license that is incompatible with Octave's. I recommend
> you build your suitesparse to run without METIS.
>
> Ben
>
>
> _______________________________________________
> Help-octave mailing list
> Help-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Bernard Desgraupes-2]

I also stumbled recently into this recently. The problem is that the  
CoreGraphics framework is in the ApplicationServices framework and the  
latter is not passed to the linker.

You must modifiy the declaration of OCTINTERP_LINK_DEPS in the file  
src/Makefile.in (or directly in the Makefile if you do not want to  
regenerate everything).
Replace
OCTINTERP_LINK_DEPS = \
   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $
(FLIBS) \
   $(OPENGL_LIBS)

by
OCTINTERP_LINK_DEPS = \
   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $
(FLIBS) \
   $(OPENGL_LIBS) $(CARBON_LIBS)


Including (CARBON_LIBS) does the trick since it will automatically  
call the ApplicationServices headers and hence the CoreGraphics headers.

If you make this change in src/Makefile.in, you must re-run the  
configuration.

cheers,

Bernard


Le 2 juin 09 à 03:21, Ben Abbott a écrit :

>
>
> On Jun 1, 2009, at 2:49 PM, Rob Mahurin wrote:
>
>> On May 31, 2009, at 4:59 PM, ws wrote:
>>> I just ALMOST compiled octave on my mac, linking to the Mac Port
>>> libraries.
>>
>>
>> Well now I have a similar question.  My missing symbols are
>>
>> Undefined symbols:
>>  "_CGDisplayPixelsHigh", referenced from:
>>      display_info::init()      in display.o
>>  "_CGDisplayPixelsWide", referenced from:
>>      display_info::init()      in display.o
>>  "_CGDisplayBitsPerPixel", referenced from:
>>      display_info::init()      in display.o
>>  "_CGMainDisplayID", referenced from:
>>      display_info::init()      in display.o
>>  "_CGDisplayScreenSize", referenced from:
>>      display_info::init()      in display.o
>> ld: symbol(s) not found
>>
>> and come when linking liboctinterp.dylib.  Any hint what I'm missing?
>>
>> This is on an Intel Mac running 10.5, where I haven't compiled Octave
>> before.  I don't seem to have the problem on my 10.4 powerbook.  Same
>> problem in 3.2.0-rc4 and in the current tip.
>>
>> Thanks,
>> Rob
>
> I took a quick glance at the sources. It looks like these are part of
> Apple's  Carbon framework.  Make sure your Xcode is up to date.
>
> Are you really running 10.5.0. I'm running 10.5.7.
>
> Ben
> _______________________________________________
> Help-octave mailing list
> Help-octave@...
> https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
>

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Rob Mahurin]

On Jun 2, 2009, at 2:16 AM, Bernard Desgraupes wrote:

> I also stumbled recently into this recently. The problem is that the
> CoreGraphics framework is in the ApplicationServices framework and the
> latter is not passed to the linker.
>
> You must modifiy the declaration of OCTINTERP_LINK_DEPS in the file
> src/Makefile.in (or directly in the Makefile if you do not want to
> regenerate everything).
> Replace
> OCTINTERP_LINK_DEPS = \
>    -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $
> (FLIBS) \
>    $(OPENGL_LIBS)
>
> by
> OCTINTERP_LINK_DEPS = \
>    -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $
> (FLIBS) \
>    $(OPENGL_LIBS) $(CARBON_LIBS)
>
>
> Including (CARBON_LIBS) does the trick since it will automatically
> call the ApplicationServices headers and hence the CoreGraphics  
> headers.
>
> If you make this change in src/Makefile.in, you must re-run the
> configuration.

Thanks Bernard, that did the trick.

Ben: I remember you had evolved a fairly elaborate set of arguments  
to ./configure.  Does something you do have this same effect?  Would  
it be appropriate to patch the sources as attached?

Rob

--
Rob Mahurin
Department of Physics and Astronomy
University of Tennessee 865 207 2594
Knoxville, TN 37996 rob@...


# HG changeset patch
# User Rob Mahurin <rob@...>
# Date 1243970119 14400
# Node ID 30197c44ff42b34f616b11e0bd1d70fab0285b18
# Parent  485eabc0cfece1d0b97ce7d21c72ca9a3e7de62a
src/Makefile.in (OCTINTERP_LINK_DEPS): Link against CARBON_LIBS.  From Bernard Desgraups <bdesgraupes@...>.

diff -r 485eabc0cfec -r 30197c44ff42 src/ChangeLog
--- a/src/ChangeLog Fri Mar 06 01:07:04 2009 -0500
+++ b/src/ChangeLog Tue Jun 02 15:15:19 2009 -0400
@@ -1,3 +1,8 @@
[phone]  Rob Mahurin  <rob@...>
+
+ * Makefile.in (OCTINTERP_LINK_DEPS): Link against CARBON_LIBS.
+ From Bernard Desgraups <bdesgraupes@...>.
+
 2009-03-05  Jaroslav Hajek  <highegg@...>
 
  * ls-hdf5.cc (add_hdf5_data): Handle diag & perm matrices.
diff -r 485eabc0cfec -r 30197c44ff42 src/Makefile.in
--- a/src/Makefile.in Fri Mar 06 01:07:04 2009 -0500
+++ b/src/Makefile.in Tue Jun 02 15:15:19 2009 -0400
@@ -296,7 +296,7 @@
 
 OCTINTERP_LINK_DEPS = \
   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $(FLIBS) \
-  $(OPENGL_LIBS)
+  $(OPENGL_LIBS) $(CARBON_LIBS)
 
 OCT_LINK_DEPS = \
   -L../libcruft $(LIBCRUFT) -L../liboctave $(LIBOCTAVE) \



_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Ben Abbott]

On Jun 2, 2009, at 3:22 PM, Rob Mahurin wrote:

> On Jun 2, 2009, at 2:16 AM, Bernard Desgraupes wrote:
>> I also stumbled recently into this recently. The problem is that the
>> CoreGraphics framework is in the ApplicationServices framework and  
>> the
>> latter is not passed to the linker.
>>
>> You must modifiy the declaration of OCTINTERP_LINK_DEPS in the file
>> src/Makefile.in (or directly in the Makefile if you do not want to
>> regenerate everything).
>> Replace
>> OCTINTERP_LINK_DEPS = \
>>   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $
>> (FLIBS) \
>>   $(OPENGL_LIBS)
>>
>> by
>> OCTINTERP_LINK_DEPS = \
>>   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS) $
>> (FLIBS) \
>>   $(OPENGL_LIBS) $(CARBON_LIBS)
>>
>>
>> Including (CARBON_LIBS) does the trick since it will automatically
>> call the ApplicationServices headers and hence the CoreGraphics  
>> headers.
>>
>> If you make this change in src/Makefile.in, you must re-run the
>> configuration.
>
>
> Thanks Bernard, that did the trick.
>
> Ben: I remember you had evolved a fairly elaborate set of arguments  
> to ./configure.  Does something you do have this same effect?  Would  
> it be appropriate to patch the sources as attached?
>
> Rob

My args to configure descend from those used by the Fink (a package  
management system for Mac OSX). Thus, I'm not very knowledgeable. I've  
cc'd Thomas Treichl as he he has a lot of experience in this area.

Ben





_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

[Thomas Treichl]

Ben Abbott schrieb:

> On Jun 2, 2009, at 3:22 PM, Rob Mahurin wrote:
>> On Jun 2, 2009, at 2:16 AM, Bernard Desgraupes wrote:
>>> I also stumbled recently into this recently. The problem is that the
>>> CoreGraphics framework is in the ApplicationServices framework and the
>>> latter is not passed to the linker.
>>>
>>> You must modifiy the declaration of OCTINTERP_LINK_DEPS in the file
>>> src/Makefile.in (or directly in the Makefile if you do not want to
>>> regenerate everything).
>>> Replace
>>> OCTINTERP_LINK_DEPS = \
>>>   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS)
>>> $(FLIBS) \
>>>   $(OPENGL_LIBS)
>>>
>>> by
>>> OCTINTERP_LINK_DEPS = \
>>>   -L../liboctave $(LIBOCTAVE) -L../libcruft $(LIBCRUFT) $(LIBS)
>>> $(FLIBS) \
>>>   $(OPENGL_LIBS) $(CARBON_LIBS)
>>>
>>>
>>> Including (CARBON_LIBS) does the trick since it will automatically
>>> call the ApplicationServices headers and hence the CoreGraphics headers.
>>>
>>> If you make this change in src/Makefile.in, you must re-run the
>>> configuration.
>>
>>
>> Thanks Bernard, that did the trick.
>>
>> Ben: I remember you had evolved a fairly elaborate set of arguments to
>> ./configure.  Does something you do have this same effect?  Would it
>> be appropriate to patch the sources as attached?
>>
>> Rob
>
> My args to configure descend from those used by the Fink (a package
> management system for Mac OSX). Thus, I'm not very knowledgeable. I've
> cc'd Thomas Treichl as he he has a lot of experience in this area.

Hi Ben and others,

thanks for inviting me into this discussion. I currently am very busy and didn't
have any chance to reply earlier. I've seen that modifications have already been
applied to the sources... Seems to be a very good solution :-)

Best regards,

   Thomas
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave