Re: Mountain Lion build

[Daniel J Sebald]

On 09/21/2012 04:46 PM, Robinson, Melvin D wrote:
> Hello,
>
> I get errors building Octave from sources on Mountain Lion. The
> compilation ultimately craters with this error:
> ld: symbol(s) not found for architecture x86_64
> collect2: ld returned 1 exit status
> make[3]: *** [liboctinterp.la] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

Well, that's a link error.


> Earlier in the build I see the following error:
>
> Undefined symbols for architecture x86_64:
> "std::_List_node_base::_M_transfer(std::_List_node_base*,
> std::_List_node_base*)", referenced from:
> std::list<std::basic_string<char, std::char_traits<char>,
> std::allocator<char> >, std::allocator<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >
>  >::_M_transfer(std::_List_iterator<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >,
> std::_List_iterator<std::basic_string<char, std::char_traits<char>,
> std::allocator<char> > >, std::_List_iterator<std::basic_string<char,
> std::char_traits<char>, std::allocator<char> > >) in
> liboctave-value.a(octave_value_liboctave_value_la-ov-class.o)

Is this a compile error, or linker error?  I'm guessing link error. (?) 
 I agree, many of these are standard C++ library members associated 
with "string" header.  The error says several routines are referencing

"std::_List_node_base::_M_transfer(std::_List_node_base*,
 std::_List_node_base*)"

Something went wrong deep within the headers/compiler, or something is 
missing from linking.  I doubt it is the latter, i.e., that just a 
single obscure function is missing from linking.

Perhaps there is some subtle error in the way Octave is calling one of 
the standard library routines or (more likely) templates.  (Or g++ 
hasn't accounted for something within its library templates.)  Are there 
any very subtle compiler warnings that you can find during compilation 
of the code within the liboctave directory?  (You'll need to clear out 
the code and recompile liboctave to watch for this, redirecting output 
would be nice.)

Dan



> I don't really know what the problem could be.
> g++ -v gives:
> butterfly:octave melrobin$ g++ -v
> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin12/4.5.4/lto-wrapper
> Target: x86_64-apple-darwin12
> Configured with: ../gcc-4.5.4/configure --prefix=/opt/local
> --build=x86_64-apple-darwin12
> --enable-languages=c,c++,objc,obj-c++,fortran,java
> --libdir=/opt/local/lib/gcc45 --includedir=/opt/local/include/gcc45
> --infodir=/opt/local/share/info --mandir=/opt/local/share/man
> --datarootdir=/opt/local/share/gcc-4.5 --with-local-prefix=/opt/local
> --with-libiconv-prefix=/opt/local --with-system-zlib --disable-nls
> --program-suffix=-mp-4.5
> --with-gxx-include-dir=/opt/local/include/gcc45/c++/
> --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
> --with-ppl=/opt/local --enable-stage1-checking --disable-multilib
> --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
> --with-ar=/opt/local/bin/ar
> --with-bugurl=https://trac.macports.org/newticket --enable-lto
> --with-pkgversion='MacPorts gcc45 4.5.4_5'
> Thread model: posix
> gcc version 4.5.4 (MacPorts gcc45 4.5.4_5)
>
> Any ideas? The error seems to come from standard C++ containers.