So - it turns out that this happens with the system libtool as well (just a little later on in the compile).

Any ideas for tracking this down?

This is kind of a big deal as I have a big code review coming up next week and I need this to work...

Derek



On Mon, Dec 9, 2013 at 9:51 PM, Derek Gaston <friedmud@gmail.com> wrote:
The offending command:

../../libtool --verbose --tag=CXX   --mode=link mpicxx -O2 -felide-constructors -funroll-loops -fstrict-aliasing -std=c++0x -Wdisabled-optimization   -fopenmp  -all-static  -o libopt.la  libopt_la-tetgen.lo libopt_la-predicates.lo


(executed in contirb/tetgen in the build directory)

I did a bit of digging and the correct file appears to be:

/bgsys/drivers/toolchain/V1R2M0-efix23/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.la


Notice the "-efix23" that is not present in the directory our libtool is looking for.  Where does libtool get this directory?  This could actually be a misconfiguration on the machine that the admins can fix... but I don't know how to hunt down the issue.

Note that libtool --verbose doesn't work here - because it's actually trying to build the command it's going to run when grep actually exits - so I can't see exactly what it's trying to do...

Derek





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