From: Roy S. <roy...@ic...> - 2012-04-19 19:47:38
|
If we configure with no METHOD defined, instead of defaulting to opt we just get a "Make.common." with no suffix. If we then build with no METHOD defined, it dies complaining that it can't find Make.common.opt. We seem to be getting hit by this bug: https://bugs.launchpad.net/ubuntu/+source/libtool/+bug/299931 on Ubuntu 10.04LTS. configure generates a libtool with /bin/bash in the shebang line, but then tries to run it from subdirectories with e.g. "/bin/sh ../../libtool blah"; this dies when dash doesn't understand the bashisms in the libtool script. I can't seem to figure a workaround; one major drawback of automake is how damn opaque it is. --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-04-19 20:00:48
|
> I can't seem to figure a workaround; one major drawback of automake is > how damn opaque it is. Thanks - actually I just hit this a minute ago on cygwin 1.7. I'll work up a fix... |
From: Roy S. <roy...@ic...> - 2012-04-19 20:10:11
|
On Thu, 19 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote: >> I can't seem to figure a workaround; one major drawback of automake is >> how damn opaque it is. > > Thanks - actually I just hit this a minute ago on cygwin 1.7. I'll work up > a fix... Thanks! Turns out this hits me on Ubuntu 11.10 too. I should have tried out the branch on more than just my Fedora laptop... --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-04-19 20:21:15
|
>>> I can't seem to figure a workaround; one major drawback of automake is >>> how damn opaque it is. >> >> Thanks - actually I just hit this a minute ago on cygwin 1.7. I'll work up >> a fix... > > Thanks! Turns out this hits me on Ubuntu 11.10 too. I should have > tried out the branch on more than just my Fedora laptop... It took a reread of the last email to see you were reporting two issues: (1) The Make.common. I just fixed in r5565 and am testing it. (2) The bash/dash nonsese I have working at home on ubuntu 11.10 by setting the CONFIG_SHELL environment variable to /bin/bash, forcing it to use the right shell. It sounds like an Ubuntu issue that should be getting fixed... You are right, though, there seems to be some breakage that configure detects shell features that are not there in the shell that gets executed. This was actually the first I heard of dash - and I found myself asking why??? Anyway, the workaround is to set CONFIG_SHELL to /bin/bash. I'll research those tickets a little more and see when the fix is expected to be there. -Ben |
From: Roy S. <roy...@ic...> - 2012-04-19 20:26:43
|
On Thu, 19 Apr 2012, Kirk, Benjamin (JSC-EG311) wrote: > (1) The Make.common. I just fixed in r5565 and am testing it. Thanks! > (2) The bash/dash nonsese I have working at home on ubuntu 11.10 by setting > the CONFIG_SHELL environment variable to /bin/bash, forcing it to use the > right shell. It sounds like an Ubuntu issue that should be getting fixed... It's almost certainly a bug in Ubuntu autotools. But if it's an Ubuntu issue that has persisted through two freaking years then it'd be nice of us to have a workaround. There's got to be some workaround - we build lots of automake-based apps here, bootstrap included, and I've never bumpted into this myself before. > You are right, though, there seems to be some breakage that configure > detects shell features that are not there in the shell that gets executed. > This was actually the first I heard of dash - and I found myself asking > why??? Efficiency. bash adds lots of fun fancy options to your shell; dash implements only the POSIX Bourne Shell behavior and so is 10% the size. This is apparently significant for things like distribution startup scripts that spawn a ton of shells. > Anyway, the workaround is to set CONFIG_SHELL to /bin/bash. I'll research > those tickets a little more and see when the fix is expected to be there. Thanks again! --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-04-19 21:31:48
|
On 4/19/12 3:26 PM, "Roy Stogner" <roy...@ic...> wrote: > It's almost certainly a bug in Ubuntu autotools. But if it's an > Ubuntu issue that has persisted through two freaking years then it'd > be nice of us to have a workaround. There's got to be some workaround > - we build lots of automake-based apps here, bootstrap included, and > I've never bumpted into this myself before. I've seen it in FIN-S, which got me thinking... It actually looks like we are inheriting it from our use of AX_PREFIX_CONFIG_H. As of 2010 they say they support dash, so I'll see where that gets us... http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=history;f=m4/ax _prefix_config_h.m4 |
From: John P. <jwp...@gm...> - 2012-04-19 23:37:53
|
After updating to 5570 on the automake branch, I now get errors about missing sfcurves.h header... I am building in a subdirectory of the SVN checkout. The steps I followed were: ./bootstrap mkdir opt_build cd opt_build ../configure --with-method=opt --prefix=/path/to/libmesh/opt_install make -j2 'make echo' reports -I../include/contrib amongst other paths. This makes no sense, though, as there is no such directory. ... CXX src/partitioning/partitioner_factory.lo CXX src/partitioning/sfc_partitioner.lo ../src/partitioning/sfc_partitioner.C:32:27: error: sfcurves.h: No such file or directory CXX src/physics/diff_physics.lo ../src/partitioning/sfc_partitioner.C: In member function 'virtual void libMesh::SFCPartitioner::_do_partition(libMesh::MeshBase&, unsigned int)': ../src/partitioning/sfc_partitioner.C:142: error: 'hilbert' is not a member of 'Sfc' ../src/partitioning/sfc_partitioner.C:145: error: 'morton' is not a member of 'Sfc' ../src/partitioning/sfc_partitioner.C:157: error: 'hilbert' is not a member of 'Sfc' make[1]: *** [src/partitioning/sfc_partitioner.lo] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all-recursive] Error 1 -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-04-20 00:09:16
|
On 4/19/12 6:37 PM, "John Peterson" <jwp...@gm...> wrote: > After updating to 5570 on the automake branch, I now get errors about > missing sfcurves.h header... > > > I am building in a subdirectory of the SVN checkout. The steps I followed > were: > > > ./bootstrap > mkdir opt_build > cd opt_build > ../configure --with-method=opt --prefix=/path/to/libmesh/opt_install > make -j2 > > 'make echo' reports -I../include/contrib amongst other paths. This > makes no sense, though, as there is no such directory. That directory is placed there so the installed tree will be serviceable by the same Make.common - alternatively I could append it only in the installed directory. But that's not the source of this particular problem. Consider it a query-replace error on my part: contrib/sfc did not exist, contrib/sfcurves was the ticket... Couple that with a preprocessor macro fix Roy just caught and it should be good now (on the automake branch). -Ben |