From: Derek G. <fri...@gm...> - 2013-12-09 21:19:59
|
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? Derek |
From: John P. <jwp...@gm...> - 2013-12-09 21:33:42
|
On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> 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? -- John |
From: Roy S. <roy...@ic...> - 2013-12-09 21:34:33
|
On Mon, 9 Dec 2013, 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? Just rerunning bootstrap ought to do it? What's the diff (or at least the version number diff) between their libtool and ours? --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-12-09 21:53:00
|
On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> wrote: > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> 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 |
From: Derek G. <fri...@gm...> - 2013-12-10 04:16:15
|
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) < ben...@na...> wrote: > > On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> > wrote: > > > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> 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 > > > |
From: Derek G. <fri...@gm...> - 2013-12-10 04:29:55
|
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 <fri...@gm...> 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) < > ben...@na...> wrote: > >> >> On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> >> wrote: >> >> > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> >> 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 >> >> >> > |
From: Derek G. <fri...@gm...> - 2013-12-10 04:51:19
|
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 <fri...@gm...> 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 <fri...@gm...> 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) < >> ben...@na...> wrote: >> >>> >>> On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> >>> wrote: >>> >>> > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> >>> 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 >>> >>> >>> >> > |
From: Derek G. <fri...@gm...> - 2013-12-10 16:38:48
|
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 <fri...@gm...> 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 <fri...@gm...> 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 <fri...@gm...> 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) < >>> ben...@na...> wrote: >>> >>>> >>>> On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> >>>> wrote: >>>> >>>> > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> >>>> 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 >>>> >>>> >>>> >>> >> > |
From: Paul T. B. <ptb...@gm...> - 2013-12-10 17:11:37
|
*sigh* didn't hit reply-all ---------- Forwarded message ---------- From: Paul T. Bauman <ptb...@gm...> Date: Tue, Dec 10, 2013 at 11:11 AM Subject: Re: [Libmesh-devel] Use system libtool? To: Derek Gaston <fri...@gm...> 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 <fri...@gm...> 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 <fri...@gm...> 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 <fri...@gm...> 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 <fri...@gm...> 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) < >>>> ben...@na...> wrote: >>>> >>>>> >>>>> On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> >>>>> wrote: >>>>> >>>>> > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> >>>>> 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Derek G. <fri...@gm...> - 2013-12-10 18:19:07
|
Well - it's BG/Q... so ultimately it is using some weird compiler - but I'm using a GCC "wrapper" for them so that it looks like GCC on the outside. It's all very tough to explain... BUT - the admins of the machine pointed me to the following: http://www.gnu.org/software/libtool/manual/html_node/Configure-notes.html And in the last bullet there it says that you can set some autoconf variables at configure time to restrict the paths libtool searches in. BUT - I really don't understand. Does this mean when configuring libMesh - or when configuring the build of libtool - does anyone know how or when I would set these variables? Derek On Tue, Dec 10, 2013 at 10:11 AM, Paul T. Bauman <ptb...@gm...> wrote: > 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 <fri...@gm...> 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 <fri...@gm...> 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 <fri...@gm...> 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 <fri...@gm...>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) < >>>>> ben...@na...> wrote: >>>>> >>>>>> >>>>>> On Dec 9, 2013, at 3:33 PM, John Peterson <jwp...@gm...> >>>>>> wrote: >>>>>> >>>>>> > On Mon, Dec 9, 2013 at 2:19 PM, Derek Gaston <fri...@gm...> >>>>>> 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 >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> >> > |
From: Paul T. B. <ptb...@gm...> - 2013-12-10 18:34:21
|
On Tue, Dec 10, 2013 at 12:18 PM, Derek Gaston <fri...@gm...> wrote: > Well - it's BG/Q... so ultimately it is using some weird compiler - but > I'm using a GCC "wrapper" for them so that it looks like GCC on the > outside. It's all very tough to explain... > Fair enough. > > BUT - the admins of the machine pointed me to the following: > > http://www.gnu.org/software/libtool/manual/html_node/Configure-notes.html > > And in the last bullet there it says that you can set some autoconf > variables at configure time to restrict the paths libtool searches in. > OK, cool, thanks for the link. > BUT - I really don't understand. Does this mean when configuring libMesh > - or when configuring the build of libtool - does anyone know how or when I > would set these variables? > When configuring libMesh (search the configure script in libMesh for this variable and you should see it). So, when configuring libMesh, do configure lt_cv_sys_lib_search_path_spec="/bgsys/drivers/toolchain/ V1R2M0-efix23/gnu-linux/powerpc64-bgq-linux/lib" <plus your other configure options> There's no dynamic linking on BG/Q (right?), so I don't think you'll need to set the dlsearch one. Sorry I can't test this directly, but I don't have access to a BG/Q system. (FWIW, I think what's happening is that libtool (usually, correctly) guesses these things based on the compiler paths and so forth, but sounds like the wonky compiler setup is too much for libtool ATM). Best, Paul |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-12-10 20:03:41
|
I'm working up a branch for you that bypasses libtool altogether - might need John to help update the moose rule that currently uses our libtool, though. Would that help for the short term? -Ben On Dec 10, 2013, at 12:34 PM, Paul T. Bauman <ptb...@gm...> wrote: > On Tue, Dec 10, 2013 at 12:18 PM, Derek Gaston <fri...@gm...> wrote: > Well - it's BG/Q... so ultimately it is using some weird compiler - but I'm using a GCC "wrapper" for them so that it looks like GCC on the outside. It's all very tough to explain... > > Fair enough. > > > BUT - the admins of the machine pointed me to the following: > > http://www.gnu.org/software/libtool/manual/html_node/Configure-notes.html > > And in the last bullet there it says that you can set some autoconf variables at configure time to restrict the paths libtool searches in. > > OK, cool, thanks for the link. > > BUT - I really don't understand. Does this mean when configuring libMesh - or when configuring the build of libtool - does anyone know how or when I would set these variables? > > When configuring libMesh (search the configure script in libMesh for this variable and you should see it). So, when configuring libMesh, do > > configure lt_cv_sys_lib_search_path_spec="/bgsys/drivers/toolchain/V1R2M0-efix23/gnu-linux/powerpc64-bgq-linux/lib" <plus your other configure options> > > There's no dynamic linking on BG/Q (right?), so I don't think you'll need to set the dlsearch one. Sorry I can't test this directly, but I don't have access to a BG/Q system. > > (FWIW, I think what's happening is that libtool (usually, correctly) guesses these things based on the compiler paths and so forth, but sounds like the wonky compiler setup is too much for libtool ATM). > > Best, > > Paul > ------------------------------------------------------------------------------ > 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: Derek G. <fri...@gm...> - 2013-12-10 20:45:44
|
I certainly wouldn't mind a branch that bypasses libtool - it could be very handy any time we run into something like this. Paul: Thanks for the explanation!!!!!! I'm going to give it a whirl! BTW - you can do dynamic linking on BG/Q - but it's tough to do and basically frowned upon - so we're not doing it for MOOSE. Derek On Tue, Dec 10, 2013 at 1:03 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > I'm working up a branch for you that bypasses libtool altogether - might > need John to help update the moose rule that currently uses our libtool, > though. > > Would that help for the short term? > > -Ben > > > On Dec 10, 2013, at 12:34 PM, Paul T. Bauman <ptb...@gm...> wrote: > > > On Tue, Dec 10, 2013 at 12:18 PM, Derek Gaston <fri...@gm...> > wrote: > > Well - it's BG/Q... so ultimately it is using some weird compiler - but > I'm using a GCC "wrapper" for them so that it looks like GCC on the > outside. It's all very tough to explain... > > > > Fair enough. > > > > > > BUT - the admins of the machine pointed me to the following: > > > > > http://www.gnu.org/software/libtool/manual/html_node/Configure-notes.html > > > > And in the last bullet there it says that you can set some autoconf > variables at configure time to restrict the paths libtool searches in. > > > > OK, cool, thanks for the link. > > > > BUT - I really don't understand. Does this mean when configuring > libMesh - or when configuring the build of libtool - does anyone know how > or when I would set these variables? > > > > When configuring libMesh (search the configure script in libMesh for > this variable and you should see it). So, when configuring libMesh, do > > > > configure > lt_cv_sys_lib_search_path_spec="/bgsys/drivers/toolchain/V1R2M0-efix23/gnu-linux/powerpc64-bgq-linux/lib" > <plus your other configure options> > > > > There's no dynamic linking on BG/Q (right?), so I don't think you'll > need to set the dlsearch one. Sorry I can't test this directly, but I don't > have access to a BG/Q system. > > > > (FWIW, I think what's happening is that libtool (usually, correctly) > guesses these things based on the compiler paths and so forth, but sounds > like the wonky compiler setup is too much for libtool ATM). > > > > Best, > > > > Paul > > > ------------------------------------------------------------------------------ > > 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 > > Lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > |
From: Derek G. <fri...@gm...> - 2013-12-10 21:01:41
|
I got libMesh to compile. At first I thought it was because of the autoconf option - but I just tried again without it (to try to recreate the problem) and it worked again! I've been in contact with the admins so I suspect they fixed something on their side. At the places it used to die I now get these messages: libtool: link: warning: `/bgsys/drivers/toolchain/V1R2M0/gnu-linux/powerpc64-bgq-linux/lib/ libgfortran.la' seems to be moved libtool: link: warning: `/bgsys/drivers/toolchain/V1R2M0/gnu-linux/powerpc64-bgq-linux/lib/libstdc++.la' seems to be moved I don't know why it wasn't able to detect that earlier... or what they might have changed - but.... IT WORKS! Thanks everyone for your help - I REALLY appreciate it! Derek On Tue, Dec 10, 2013 at 1:45 PM, Derek Gaston <fri...@gm...> wrote: > I certainly wouldn't mind a branch that bypasses libtool - it could be > very handy any time we run into something like this. > > Paul: Thanks for the explanation!!!!!! I'm going to give it a whirl! > > BTW - you can do dynamic linking on BG/Q - but it's tough to do and > basically frowned upon - so we're not doing it for MOOSE. > > Derek > > > > > On Tue, Dec 10, 2013 at 1:03 PM, Kirk, Benjamin (JSC-EG311) < > ben...@na...> wrote: > >> I'm working up a branch for you that bypasses libtool altogether - might >> need John to help update the moose rule that currently uses our libtool, >> though. >> >> Would that help for the short term? >> >> -Ben >> >> >> On Dec 10, 2013, at 12:34 PM, Paul T. Bauman <ptb...@gm...> wrote: >> >> > On Tue, Dec 10, 2013 at 12:18 PM, Derek Gaston <fri...@gm...> >> wrote: >> > Well - it's BG/Q... so ultimately it is using some weird compiler - but >> I'm using a GCC "wrapper" for them so that it looks like GCC on the >> outside. It's all very tough to explain... >> > >> > Fair enough. >> > >> > >> > BUT - the admins of the machine pointed me to the following: >> > >> > >> http://www.gnu.org/software/libtool/manual/html_node/Configure-notes.html >> > >> > And in the last bullet there it says that you can set some autoconf >> variables at configure time to restrict the paths libtool searches in. >> > >> > OK, cool, thanks for the link. >> > >> > BUT - I really don't understand. Does this mean when configuring >> libMesh - or when configuring the build of libtool - does anyone know how >> or when I would set these variables? >> > >> > When configuring libMesh (search the configure script in libMesh for >> this variable and you should see it). So, when configuring libMesh, do >> > >> > configure >> lt_cv_sys_lib_search_path_spec="/bgsys/drivers/toolchain/V1R2M0-efix23/gnu-linux/powerpc64-bgq-linux/lib" >> <plus your other configure options> >> > >> > There's no dynamic linking on BG/Q (right?), so I don't think you'll >> need to set the dlsearch one. Sorry I can't test this directly, but I don't >> have access to a BG/Q system. >> > >> > (FWIW, I think what's happening is that libtool (usually, correctly) >> guesses these things based on the compiler paths and so forth, but sounds >> like the wonky compiler setup is too much for libtool ATM). >> > >> > Best, >> > >> > Paul >> > >> ------------------------------------------------------------------------------ >> > 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 >> > Lib...@li... >> > https://lists.sourceforge.net/lists/listinfo/libmesh-devel >> >> > |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2013-12-10 21:04:34
|
On Dec 10, 2013, at 3:01 PM, Derek Gaston <fri...@gm...> wrote: > I don't know why it wasn't able to detect that earlier... or what they might have changed - but.... IT WORKS! > > Thanks everyone for your help - I REALLY appreciate it! Glad to hear that - getting a no-libtool build is proving to be a bit of a challenge because of our 'convenience libraries.' I'll still work on this option but at a low level. -Ben |
From: Derek G. <fri...@gm...> - 2013-12-10 21:07:32
|
Sounds good Ben - I do still think there is value in having that option - but it's something we can get at a later date. I'm still trying to recreate the problem now - I don't like it when things just "start working"... I'm asking the admin if they changed something on their side... Derek On Tue, Dec 10, 2013 at 2:04 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > On Dec 10, 2013, at 3:01 PM, Derek Gaston <fri...@gm...> > wrote: > > > I don't know why it wasn't able to detect that earlier... or what they > might have changed - but.... IT WORKS! > > > > Thanks everyone for your help - I REALLY appreciate it! > > Glad to hear that - getting a no-libtool build is proving to be a bit of a > challenge because of our 'convenience libraries.' > > I'll still work on this option but at a low level. > > -Ben > > > |
From: Derek G. <fri...@gm...> - 2013-12-10 22:01:38
|
Ok: It turns out that one of the admins symlinked the old directory to the new one... that's why it's working now and why libtool is printing out those warnings. It's definitely not libMesh's fault - definitely a problem with the configuration on the machine. I just wonder why none of the other codes they're building on that machine aren't having trouble... Thanks again everyone for the help! Derek On Tue, Dec 10, 2013 at 2:07 PM, Derek Gaston <fri...@gm...> wrote: > Sounds good Ben - I do still think there is value in having that option - > but it's something we can get at a later date. > > I'm still trying to recreate the problem now - I don't like it when things > just "start working"... I'm asking the admin if they changed something on > their side... > > Derek > > > On Tue, Dec 10, 2013 at 2:04 PM, Kirk, Benjamin (JSC-EG311) < > ben...@na...> wrote: > >> On Dec 10, 2013, at 3:01 PM, Derek Gaston <fri...@gm...> >> wrote: >> >> > I don't know why it wasn't able to detect that earlier... or what they >> might have changed - but.... IT WORKS! >> > >> > Thanks everyone for your help - I REALLY appreciate it! >> >> Glad to hear that - getting a no-libtool build is proving to be a bit of >> a challenge because of our 'convenience libraries.' >> >> I'll still work on this option but at a low level. >> >> -Ben >> >> >> > |