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 >>> >>> >>> >> > |