*sigh* didn't hit reply-all

---------- Forwarded message ----------
From: Paul T. Bauman <ptbau...@gmail.com>
Date: Tue, Dec 10, 2013 at 11:11 AM
Subject: Re: [Libmesh-devel] Use system libtool?
To: Derek Gaston <fried...@gmail.com>


This is strange. What compilers are you using? This almost looks to me like
they did a system update, but didn't update the system gcc install.

In attempt to just and get you running ASAP (apologies if you already tried
this), that looks like a core system path and that will probably be inside
the libtool script (it's just a bash script). As a quick, ugly ugly hack,
can you search through the libtool script for V1R2M0 and replace with the
new path name? Note the libtool script gets generated after configure, so
if you rerun configure, you're changes will get wiped out.


On Tue, Dec 10, 2013 at 10:38 AM, Derek Gaston <fried...@gmail.com> wrote:

> 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 <fried...@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 <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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>
> _______________________________________________
> Libmesh-devel mailing list
> Libmesh-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-devel
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&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