Running bootstrap doesn't fix it.

Neither does running "autoreconf -iv --force"

Only thing that fixes it so far is soft-linking the system libtool...

On Mon, Dec 9, 2013 at 9:16 PM, Derek Gaston <> wrote:
It's a problem when building tetgen (well - it shows up there first):


/bin/grep: /bgsys/drivers/toolchain/V1R2M0/gnu-linux/powerpc64-bgq-linux/lib/ No such file or directory

/bin/sed: can't read /bgsys/drivers/toolchain/V1R2M0/gnu-linux/powerpc64-bgq-linux/lib/ No such file or directory

libtool: link: `/bgsys/drivers/toolchain/V1R2M0/gnu-linux/powerpc64-bgq-linux/lib/' is not a valid libtool archive

make[2]: *** [] Error 1

make[2]: Leaving directory `/gpfs/mira-home/gastdr/projects/libmesh/build/contrib/tetgen'

The weird thing is that /bgsys/drivers/toolchain/V1R2M0 doesn't exist... I have no idea no idea how it's picking it up... but the system libtool doesn't have that issue...


On Mon, Dec 9, 2013 at 2:52 PM, Kirk, Benjamin (JSC-EG311) <> wrote:

On Dec 9, 2013, at 3:33 PM, John Peterson <>

> On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <> wrote:
>> So - I'm back at trying to get everything running on BG/Q (Mira) at
>> Argonne... and I hit a snag where our supplied libtool is doing something
>> bad - but if I just move it out of the way and set a soft-link to the system
>> libtool then everything is working fine.
>> Is there a way to tell our build system not to use our included libtool at
>> all?
> Is the error during building libmesh?  What is the error?

I'm interested in the answer as well, but...

boostrap has some simple logic in there to look for a preferred version of libtool and build ours.  But at the end of the day, all bootstrap does is run

$ autoreconf -iv --force

so if your path is set up such that

1) autoreconf
2) automake
3) libtool

point to the versions you desire, just run

$  autoreconf -iv --force