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 <fried...@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 <fried...@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.k...@nasa.gov> wrote:
>>
>>>
>>> On Dec 9, 2013, at 3:33 PM, John Peterson <jwpeter...@gmail.com>
>>>  wrote:
>>>
>>> > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fried...@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
>>>
>>>
>>>
>>
>
------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to