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 <friedmud@gmail.com> wrote:
It's a problem when building tetgen (well - it shows up there first):


  CXXLD    libopt.la

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

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

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

make[2]: *** [libopt.la] 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...

Derek




On Mon, Dec 9, 2013 at 2:52 PM, Kirk, Benjamin (JSC-EG311) <benjamin.kirk@nasa.gov> wrote:

On Dec 9, 2013, at 3:33 PM, John Peterson <jwpeterson@gmail.com>
 wrote:

> On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <friedmud@gmail.com> 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