master doesn't build on Mac OS X 10.6.8

[libmesh]

master doesn't build on Mac OS X 10.6.8

[guyer]

On Feb 14, 2013, at 3:32 PM, jwpeterson wrote:

Confirmed that ea92d11 builds static for me with Tecplot enabled. Thanks!

Likewise. I'll try the clang build next and let you know.

[benkirk]

On Feb 13, 2013, at 3:32 PM, guyer [email protected] wrote:

make fails with:

*** Warning: Linking the shared library libcontrib_opt.la against the
*** static library ../contrib/tecplot/lib/x86_64-apple-darwin10.8.0/tecio.a is not portable!
copying selected object files to avoid basename conflicts...
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file for cputype (16777234) cpusubtype (0) is not an object file (bad magic number)
ar: internal ranlib command failed
make[2]: *** [libcontrib_opt.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I was able to narrow things down a bit with git bisect to

The first bad commit could be any of:
6431808
fd72114
6a41dc4
We cannot bisect more!

Thanks for the report.

Can you try

$ ./configure --disable-tecplot --enable-tecio …

and report your results?

I am planning on switching that default, but am working through a recent NetCDF switch too and want to make sure that's worked out first… This may provide more motivation though!

-Ben

[jwpeterson]

On Wed, Feb 13, 2013 at 2:32 PM, guyer [email protected] wrote:

make fails with:

*** Warning: Linking the shared library libcontrib_opt.la against the
*** static library ../contrib/tecplot/lib/x86_64-apple-darwin10.8.0/tecio.a is not portable!
copying selected object files to avoid basename conflicts...
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file for cputype (16777234) cpusubtype (0) is not an object file (bad magic number)
ar: internal ranlib command failed
make[2]: *** [libcontrib_opt.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I was able to narrow things down a bit with git bisect to

The first bad commit could be any of:
6431808
fd72114
6a41dc4
We cannot bisect more!

You may try configuring with --disable-tecplot.

John

[jwpeterson]

On Wed, Feb 13, 2013 at 2:32 PM, guyer [email protected] wrote:

make fails with:

*** Warning: Linking the shared library libcontrib_opt.la against the
*** static library ../contrib/tecplot/lib/x86_64-apple-darwin10.8.0/tecio.a is not portable!
copying selected object files to avoid basename conflicts...
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file for cputype (16777234) cpusubtype (0) is not an object file (bad magic number)
ar: internal ranlib command failed
make[2]: *** [libcontrib_opt.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I was able to narrow things down a bit with git bisect to

The first bad commit could be any of:
6431808

This one is "merged libmesh.automake branch" which is almost certainly
where it would have stopped working.

Probably we never tried to run "ranlib" before autotools came along, and
ranlib does not seem to like tecio.a very much.

John

[guyer]

On Feb 13, 2013, at 4:34 PM, Benjamin S. Kirk wrote:

On Feb 13, 2013, at 3:32 PM, guyer [email protected] wrote:

Thanks for the report.

Can you try

$ ./configure --disable-tecplot --enable-tecio …

and report your results?

Thanks for the quick response from you and jwpeterson. Now it runs much longer, but still fails with

CXXLD    getpot_parse-opt
Undefined symbols:
  "_nc_def_var_deflate", referenced from:
      _ex_compress_variable in libmesh_opt.a(libopt_la-ex_utils.o)
  "Hilbert::coordsToIndex(CFixBitVec const*, int, int, CBigBitVec&)", referenced from:
      Hilbert::HilbertIndices (anonymous namespace)::get_hilbert_index<libMesh::Elem>(libMesh::Elem const*, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o)
      Hilbert::HilbertIndices (anonymous namespace)::get_hilbert_index<libMesh::Node>(libMesh::Node const*, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o)
      (anonymous namespace)::get_hilbert_index(libMesh::Point const&, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [getpot_parse-opt] Error 1
make: *** [all-recursive] Error 1

[jwpeterson]

On Wed, Feb 13, 2013 at 2:45 PM, John Peterson [email protected] wrote:

On Wed, Feb 13, 2013 at 2:32 PM, guyer [email protected] wrote:

make fails with:

*** Warning: Linking the shared library libcontrib_opt.la against the
*** static library
../contrib/tecplot/lib/x86_64-apple-darwin10.8.0/tecio.a is not portable!
copying selected object files to avoid basename conflicts...
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file
for cputype (16777234) cpusubtype (0) is not an object file (bad magic
number)
ar: internal ranlib command failed
make[2]: *** [libcontrib_opt.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I was able to narrow things down a bit with git bisect to

The first bad commit could be any of:
6431808

This one is "merged libmesh.automake branch" which is almost certainly where
it would have stopped working.

Probably we never tried to run "ranlib" before autotools came along, and
ranlib does not seem to like tecio.a very much.

Speaking of ranlib, on my Mac I ran it directly on the tecio.a binary

/usr/bin/ranlib ./contrib/tecplot/lib/x86_64-apple-darwin10.7.0/tecio.a

And it changed the file somehow (can't tell exactly how because it's binary):

git ci -a -m""
git log -p --stat

.../tecplot/lib/x86_64-apple-darwin10.7.0/tecio.a | Bin 1165672 ->
1165712 bytes

Maybe try this and turn tecplot back on, see if it makes any difference?

John

[benkirk]

On Feb 13, 2013, at 3:58 PM, guyer [email protected] wrote:

On Feb 13, 2013, at 3:32 PM, guyer [email protected] wrote:

Thanks for the report.

Can you try

$ ./configure --disable-tecplot --enable-tecio …

and report your results?

Thanks for the quick response from you and jwpeterson. Now it runs much longer, but still fails with

CXXLD getpot_parse-opt 
Undefined symbols: 
"_nc_def_var_deflate", referenced from: 
_ex_compress_variable in libmesh_opt.a(libopt_la-ex_utils.o) 
"Hilbert::coordsToIndex(CFixBitVec const*, int, int, CBigBitVec&)", referenced from: 
Hilbert::HilbertIndices (anonymous namespace)::get_hilbert_index<libMesh::Elem>(libMesh::Elem const*, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o) 
Hilbert::HilbertIndices (anonymous namespace)::get_hilbert_index<libMesh::Node>(libMesh::Node const*, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o) 
(anonymous namespace)::get_hilbert_index(libMesh::Point const&, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o) 
ld: symbol(s) not found 
collect2: ld returned 1 exit status 
make[1]: *** [getpot_parse-opt] Error 1 
make: *** [all-recursive] Error 1

It looks like you may be building with static libraries? Please provide the summary you get from configure, along with your command line arguments.

This is certainly being caused by the new NetCDF stuff I am working through - you can revert to the old versions with

$ ./configure --disable-tecplot --enable-tecio --with-netcdf=old --with-exodus=old --with-nemesis=old …

-Ben

[roystgnr]

On Wed, 13 Feb 2013, guyer wrote:

Undefined symbols:
...
"Hilbert::coordsToIndex(CFixBitVec const*, int, int, CBigBitVec&)", referenced from:

I'd be very interested in seeing this resolved; a couple of the same
missing symbols are what's currently keeping us from compiling with
--enable-libHilbert on Cygwin. Granted, we haven't supported Cygwin
in quite some time, but it would be nice to support them again since

we're so close.

Roy

[jwpeterson]

On Wed, Feb 13, 2013 at 2:58 PM, guyer [email protected] wrote:

On Feb 13, 2013, at 4:34 PM, Benjamin S. Kirk wrote:

On Feb 13, 2013, at 3:32 PM, guyer [email protected] wrote:

Thanks for the report.

Can you try

$ ./configure --disable-tecplot --enable-tecio …

and report your results?

Thanks for the quick response from you and jwpeterson. Now it runs much
longer, but still fails with

CXXLD getpot_parse-opt
Undefined symbols:
"_nc_def_var_deflate", referenced from:

We've seen this before, it was related to building new netcdf without HDF5,
but I thought @benkirk already fixed it.

Is it possible that configure thought it found HDF5 but really didn't?

Maybe also pass --disable-hdf5 to configure...

John

[jwpeterson]

On Wed, Feb 13, 2013 at 3:00 PM, John Peterson [email protected] wrote:

On Wed, Feb 13, 2013 at 2:45 PM, John Peterson [email protected] wrote:

On Wed, Feb 13, 2013 at 2:32 PM, guyer [email protected] wrote:

make fails with:

*** Warning: Linking the shared library libcontrib_opt.la against the
*** static library
../contrib/tecplot/lib/x86_64-apple-darwin10.8.0/tecio.a is not portable!
copying selected object files to avoid basename conflicts...
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file
for cputype (16777234) cpusubtype (0) is not an object file (bad magic
number)
ar: internal ranlib command failed
make[2]: *** [libcontrib_opt.la] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1

I was able to narrow things down a bit with git bisect to

The first bad commit could be any of:
6431808

This one is "merged libmesh.automake branch" which is almost certainly where
it would have stopped working.

Probably we never tried to run "ranlib" before autotools came along, and
ranlib does not seem to like tecio.a very much.

Speaking of ranlib, on my Mac I ran it directly on the tecio.a binary

/usr/bin/ranlib ./contrib/tecplot/lib/x86_64-apple-darwin10.7.0/tecio.a

And it changed the file somehow (can't tell exactly how because it's binary):

git ci -a -m""
git log -p --stat

.../tecplot/lib/x86_64-apple-darwin10.7.0/tecio.a | Bin 1165672 ->
1165712 bytes

Maybe try this and turn tecplot back on, see if it makes any difference?

Eh, this didn't seem to change anything for me, still fails on static builds.

John

[jwpeterson]

On Wed, Feb 13, 2013 at 3:45 PM, John Peterson [email protected] wrote:

Eh, this didn't seem to change anything for me, still fails on static
builds.

Is it the case that archive files cannot be added to other archives on OSX?

nm ./build/contrib/.libs/libcontrib_opt.a
nm: archive member: ./build/contrib/.libs/libcontrib_opt.a(tecio.a) is a
fat file (not allowed in an archive)

From the output of "make V=1" we can see that this is indeed what libtool
is trying to do:

libtool: link: ar cru .libs/libcontrib_opt.a
../../contrib/tecplot/lib/x86_64-apple-darwin12.2.0/tecio.a [various and
sundry sundry contributed .o files...]
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file
for cputype (16777234) cpusubtype (0) is not an object file (bad magic
number)
ar: internal ranlib command failed

Note that tecio.a is the only .a file it tries to link into
libcontrib_opt.a this way.

Could we work around this by not trying to link tecio.a into
libcontrib_opt.a?

That is, could we have tecio.a get installed in $LIBMESH_DIR/lib, similar
to what happens with libnetcdf.a, and make sure it gets added to the
"dependency_libs" in libmesh_opt.la?

John

[benkirk]

I think that's the right idea - ill work on the static lib config tomorrow.

-Ben

On Feb 13, 2013, at 5:21 PM, "jwpeterson" <[email protected]mailto:[email protected]> wrote:

On Wed, Feb 13, 2013 at 3:45 PM, John Peterson <[email protected]mailto:[email protected]> wrote:

Eh, this didn't seem to change anything for me, still fails on static
builds.

Is it the case that archive files cannot be added to other archives on OSX?

nm ./build/contrib/.libs/libcontrib_opt.a
nm: archive member: ./build/contrib/.libs/libcontrib_opt.a(tecio.a) is a
fat file (not allowed in an archive)

From the output of "make V=1" we can see that this is indeed what libtool
is trying to do:

libtool: link: ar cru .libs/libcontrib_opt.a
../../contrib/tecplot/lib/x86_64-apple-darwin12.2.0/tecio.a [various and
sundry sundry contributed .o files...]
/usr/bin/ranlib: archive member: .libs/libcontrib_opt.a(tecio.a) fat file
for cputype (16777234) cpusubtype (0) is not an object file (bad magic
number)
ar: internal ranlib command failed

Note that tecio.a is the only .a file it tries to link into
libcontrib_opt.a this way.

Could we work around this by not trying to link tecio.a into
libcontrib_opt.a?

That is, could we have tecio.a get installed in $LIBMESH_DIR/lib, similar
to what happens with libnetcdf.a, and make sure it gets added to the
"dependency_libs" in libmesh_opt.la?

John

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/42#issuecomment-13524518.

[guyer]

On Feb 13, 2013, at 5:04 PM, Benjamin S. Kirk wrote:

It looks like you may be building with static libraries? Please provide the summary you get from configure, along with your command line arguments.

This is certainly being caused by the new NetCDF stuff I am working through - you can revert to the old versions with

$ ./configure --disable-tecplot --enable-tecio --with-netcdf=old --with-exodus=old --with-nemesis=old …

This still fails at the same point with

  CXXLD    getpot_parse-opt
Undefined symbols:
  "_nc_def_var_deflate", referenced from:
      _ex_compress_variable in libmesh_opt.a(libopt_la-ex_utils.o)
  "Hilbert::coordsToIndex(CFixBitVec const*, int, int, CBigBitVec&)", referenced from:
      Hilbert::HilbertIndices (anonymous namespace)::get_hilbert_index<libMesh::Elem>(libMesh::Elem const*, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o)
      Hilbert::HilbertIndices (anonymous namespace)::get_hilbert_index<libMesh::Node>(libMesh::Node const*, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o)
      (anonymous namespace)::get_hilbert_index(libMesh::Point const&, libMesh::MeshTools::BoundingBox const&)in libmesh_opt.a(libmesh_opt_la-mesh_communication_global_indices.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make[1]: *** [getpot_parse-opt] Error 1
make: *** [all-recursive] Error 1

I've posted the config.log at https://gist.github.com/guyer/4954871#file-config-log

[guyer]

On Feb 13, 2013, at 6:21 PM, jwpeterson wrote:

Is it the case that archive files cannot be added to other archives on OSX?

According to a comment I ran across while googling the error message http://trac.macports.org/ticket/29261#comment:6, apparently no it can't. No cite for that statement, though.

[benkirk]

Looks like you pulled master at fef9612, and the nc_deflate business has been fixed since then.

Still, I'll see what I can do because I suspect that will not touch the Hilbert issue.

[benkirk]

master HEAD works for me just fine on my 10.8.2 machine using only the Xcode gcc, at leas until well into the examples when we see a failed dynamic cast.

Here is my config:
https://gist.github.com/benkirk/4955732

And the eventual failure is

***************************************************************
* Running Example adaptivity_ex2:
*   example-dbg -n_timesteps 25 -n_refinements 5 -output_freq 10 -init_timestep 0 
***************************************************************

Usage:
     /Users/benkirk/codes/libmesh/xcode/examples/adaptivity/adaptivity_ex2/.libs/example-dbg -init_timestep 0
OR
     /Users/benkirk/codes/libmesh/xcode/examples/adaptivity/adaptivity_ex2/.libs/example-dbg -read_solution -init_timestep 26

Running: /Users/benkirk/codes/libmesh/xcode/examples/adaptivity/adaptivity_ex2/.libs/example-dbg -n_timesteps 25 -n_refinements 5 -output_freq 10 -init_timestep 0

 Mesh Information:
  mesh_dimension()=2
  spatial_dimension()=3
  n_nodes()=6273
    n_local_nodes()=6273
  n_elem()=13650
    n_local_elem()=13650
    n_active_elem()=10240
  n_subdomains()=1
  n_partitions()=1
  n_processors()=1
  n_threads()=1
  processor_id()=0

Failed to convert N7libMesh6SystemE pointer to PN7libMesh15TransientSystemINS_20LinearImplicitSystemEEE
The N7libMesh6SystemE appears to be a N7libMesh15TransientSystemINS_20LinearImplicitSystemEEE
Stack frames: 10
0: 0   libmesh_dbg.0.dylib                 0x000000010e7a7a3c libMesh::print_trace(std::ostream&) + 44
1: 1   example-dbg                         0x000000010e63b9a7 libMesh::TransientSystem<libMesh::LinearImplicitSystem>* libMesh::libmesh_cast_ptr<libMesh::TransientSystem<libMesh::LinearImplicitSystem>*, libMesh::System>(libMesh::System*) + 487
2: 2   example-dbg                         0x000000010e63bdc5 libMesh::TransientSystem<libMesh::LinearImplicitSystem>& libMesh::EquationSystems::get_system<libMesh::TransientSystem<libMesh::LinearImplicitSystem> >(std::string const&) + 637
3: 3   example-dbg                         0x000000010e6183ae init_cd(libMesh::EquationSystems&, std::string const&) + 686
4: 4   libmesh_dbg.0.dylib                 0x000000010f25ee05 libMesh::System::user_initialization() + 73
5: 5   libmesh_dbg.0.dylib                 0x000000010f274574 libMesh::System::init() + 120
6: 6   libmesh_dbg.0.dylib                 0x000000010f1eb1df libMesh::EquationSystems::init() + 1571
7: 7   example-dbg                         0x000000010e6196cb main + 3867
8: 8   libdyld.dylib                       0x00007fff91a1d7e1 start + 0
9: 9   ???                                 0x0000000000000009 0x0 + 9
[0] ../../../include/libmesh/libmesh_common.h, line 342, compiled Feb 14 2013 at 13:52:14
libc++abi.dylib: terminate called throwing an exception
/Users/benkirk/codes/libmesh/xcode/../examples/run_common.sh: line 50: 55951 Abort trap: 6           $LIBMESH_RUN ./$executable $options $LIBMESH_OPTIONS
FAIL: run.sh
====================================================
1 of 1 test failed
Please report to [email protected]
====================================================

Can you make sure you are at the latest revision?

[guyer]

Note: My email replies aren't going through anymore for some reason, so this might get posted twice

On Feb 14, 2013, at 1:40 PM, Benjamin S. Kirk wrote:

Looks like you pulled master at fef9612, and the nc_deflate business has been fixed since then.

I fetched and merged up through 9b92334 and still get the same errors ("bad magic number" errors from the default ./configure; make and the undefined Hilbert symbols from ./configure --disable-tecplot --enable-tecio --with-netcdf=old --with-exodus=old --with-nemesis=old.

I don't see nc_deflate mentioned in any of my builds, either before or after updating master. What does it affect?

I don't know whether it's germane, but given commit 392a51e (need automake 1.12 for properly bundling netcdf, it seems for Ubuntu-LTS), I note that my build warns about not having automake-1.12. I haven't modified any of the files, so I don't know if this matters.:

CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/guyer/Documents/research/libmesh/build-aux/missing --run aclocal-1.12 -I m4
/Users/guyer/Documents/research/libmesh/build-aux/missing: line 51: aclocal-1.12: command not found
WARNING: 'aclocal-1.12' is missing on your system.  You should only need it if
       you modified 'acinclude.m4' or 'configure.ac'.  You might want
       to install the Automake and Perl packages.  Grab them from
       any GNU archive site.
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /Users/guyer/Documents/research/libmesh/build-aux/missing --run autoconf
cd . && /bin/sh /Users/guyer/Documents/research/libmesh/build-aux/missing --run automake-1.12 --gnu
/Users/guyer/Documents/research/libmesh/build-aux/missing: line 51: automake-1.12: command not found
WARNING: 'automake-1.12' is missing on your system.  You should only need it if
       you modified 'Makefile.am', 'acinclude.m4' or 'configure.ac'.
       You might want to install the Automake and Perl packages.
       Grab them from any GNU archive site.
aclocal.m4:20: warning: this file was generated for autoconf 2.69.
You have another version of autoconf.  It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically 'autoreconf'.
configure.ac:62: error: Autoconf version 2.62 or higher is required
m4/prefix_config.m4:209: AX_PREFIX_CONFIG_H is expanded from...
configure.ac:62: the top level
autom4te: /usr/bin/gm4 failed with exit status: 63
WARNING: 'autoconf' is probably too old.  You should only need it if
       you modified 'configure.ac'.  You might want to install the
       Autoconf and GNU m4 packages.  Grab them from any GNU
       archive site.

[benkirk]

That won't matter, provided you are not modifying the build system.

once interesting thing on my end, though, running my Xcode clang compilers work all the way through.

how about

$ make distclean
$ ./configure ... CXX=clang++ CC=clang
$ make -j 4 && make -j 4 check

of course, modifying the -j4 for however many processors you have?

I'd like to rule out Apple's gcc-4.2 as causing a problem, as it has been the source of a lot of headache over the years.

[jwpeterson]

Confirmed that ea92d11 builds static for me with Tecplot enabled. Thanks!

[benkirk]

No problem, I wanted to fix that before switching to default tecio from source instead, mostly for the pain of it I guess! ;-P

[benkirk]

Any news on this front?