From: John P. <jwp...@gm...> - 2012-11-07 21:41:06
|
Looks like something that hasn't been merged over to trunk yet, because I haven't seen the issue there. This is for an "almost stock" Mountain Lion install. I have some stuff built by hand, no macports installed though. No Xquartz stuff. Also looks like ./configure --disable-tecplot *does not* work around the error Making all in contrib/tecplot/tecio In file included from tecsrc/alloc.cpp:2:0: tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directoryIn file included from tecsrc/TranslatedString.cpp:2:0: tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directoryIn file included from tecsrc/auxdata.cpp:2:0: tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directoryIn file included from tecsrc/arrlist.cpp:2:0: tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directory -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-07 22:08:59
|
OK, try --disable-tecio --enable-tecplot. As of a few months ago, I got the TecIO source from Tecplot and permission to redistribute that. I integrated that into the automake branch as an option to build it from source instead of using a .a. As of a few hours ago I made that the default. So --enable-tecplot is the old behavior. --enable-tecio controls this woe. Sorry for the noise. On Nov 7, 2012, at 3:40 PM, John Peterson <jwp...@gm...> wrote: > Looks like something that hasn't been merged over to trunk yet, because I haven't seen the issue there. > > This is for an "almost stock" Mountain Lion install. I have some stuff built by hand, no macports installed though. No Xquartz stuff. > > Also looks like ./configure --disable-tecplot *does not* work around the error > > Making all in contrib/tecplot/tecio > In file included from tecsrc/alloc.cpp:2:0: > tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directoryIn file included from tecsrc/TranslatedString.cpp:2:0: > tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directoryIn file included from tecsrc/auxdata.cpp:2:0: > tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directoryIn file included from tecsrc/arrlist.cpp:2:0: > tecsrc/MASTER.h:508:31: fatal error: X11/Intrinsic.h: No such file or directory > > > -- > John > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d_______________________________________________ > Libmesh-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: John P. <jwp...@gm...> - 2012-11-07 22:40:31
|
On Wed, Nov 7, 2012 at 3:08 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > So --enable-tecplot is the old behavior. > --enable-tecio controls this woe. > I see. Thanks for the info, it does indeed work with --disable-tecio. BTW, perhaps you can comment on the following: I think I have gotten to the bottom of our troubles with building our own compilers from source on Mac. If I download and build libtool from source, and change the top-level Makefile's link command to: @libtool --tag=CXX --quiet --mode=link $(libmesh_CXX) $(libmesh_CXXSHAREDFLAG) -o $(mesh_library) $(objects) $(libmesh_LDFLAGS) i.e. just *prepend* "libtool --tag=CXX --quiet --mode=link" to what we already have there, most of the random segfaults we were seeing are magically gone! It works 100% if I also build the triangle shared library in contrib with the same method. This libtool trick has been tested with both GCC 4.6.x and 4.7.x series compilers, so I don't think the issue was ever compiler-related, just shared-library-creation related. Some questions: .) Do you know what magic libtool could possibly be doing here? .) On the automake branch, I still get the (system-level) segfaults with my hand-built compilers. Do you know how automake builds shared libraries? Is there any way I could try this libtool trick with the automake branch of libmesh as well? -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-07 22:50:16
|
On Nov 7, 2012, at 4:40 PM, John Peterson <jwp...@gm...> wrote: > Some questions: > > .) Do you know what magic libtool could possibly be doing here? > No, but maybe without the --quiet it will tell you? > .) On the automake branch, I still get the (system-level) segfaults with my hand-built compilers. Do you know how automake builds shared libraries? Is there any way I could try this libtool trick with the automake branch of libmesh as well? if you run $ make V=1 it will turn on verbose rules, which should be very instructive. Sorry, that's all I've got. -Ben |
From: Paul T. B. <ptb...@gm...> - 2012-11-07 22:50:42
|
On Wed, Nov 7, 2012 at 4:40 PM, John Peterson <jwp...@gm...> wrote: > > .) Do you know what magic libtool could possibly be doing here? > Sorry I haven't had time to look into it myself, but one of the things libtool will do is add flags in a system dependent way (and occasionally strip some out if you aren't careful and made a typo in an option or something). Again, I haven't had time to look, but if you feed configure --disable-silent-rules, this will produce verbose output during compile and linking. It will first show the lines that were passed to libtool and then show the line that it actually used. Doing a diff on those should help elucidate what's going on. > .) On the automake branch, I still get the (system-level) segfaults with > my hand-built compilers. > What are the errors? > Do you know how automake builds shared libraries? > libtool is what takes care of this. Again, you'll see the command it uses at link time with the --disable-silent-rules configure option. > Is there any way I could try this libtool trick with the automake branch > of libmesh as well? > libtool should be doing the "trick" you showed. So are you in the situation that trunk and branch are failing in different ways with hand-built GCC? Best, Paul |
From: Paul T. B. <ptb...@gm...> - 2012-11-07 23:04:45
|
On Wed, Nov 7, 2012 at 4:50 PM, Paul T. Bauman <ptb...@gm...> wrote: > On Wed, Nov 7, 2012 at 4:40 PM, John Peterson <jwp...@gm...>wrote: > > >> .) On the automake branch, I still get the (system-level) segfaults with >> my hand-built compilers. >> > > What are the errors? > Latest automake branch is running cleanly for me (in dbg, need to try the others). Anythign special you guys are feeding to $LIBMESH_RUN or $LIBMESH_OPTIONS? Also, did you rename the libtool executable (e.g. when macports builds autotools, it installs libtool as glibtool), because there is a native libtool installed that's Apple's thing and I'm not sure if glibtool is using it or not. |
From: Cody P. <cod...@gm...> - 2012-11-08 00:30:28
|
Sent from my iPhone On Nov 7, 2012, at 4:04 PM, "Paul T. Bauman" <ptb...@gm...> wrote: On Wed, Nov 7, 2012 at 4:50 PM, Paul T. Bauman <ptb...@gm...> wrote: > On Wed, Nov 7, 2012 at 4:40 PM, John Peterson <jwp...@gm...>wrote: > > >> .) On the automake branch, I still get the (system-level) segfaults with >> my hand-built compilers. >> > > Oddly enough we only see these seg faults in opt mode. Cody What are the errors? > Latest automake branch is running cleanly for me (in dbg, need to try the others). Anythign special you guys are feeding to $LIBMESH_RUN or $LIBMESH_OPTIONS? Also, did you rename the libtool executable (e.g. when macports builds autotools, it installs libtool as glibtool), because there is a native libtool installed that's Apple's thing and I'm not sure if glibtool is using it or not. ------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d _______________________________________________ Libmesh-devel mailing list Lib...@li... https://lists.sourceforge.net/lists/listinfo/libmesh-devel |
From: John P. <jwp...@gm...> - 2012-11-08 16:21:34
|
On Wed, Nov 7, 2012 at 3:50 PM, Paul T. Bauman <ptb...@gm...> wrote: > .) On the automake branch, I still get the (system-level) segfaults with >> my hand-built compilers. >> > > What are the errors? > The error is an unhelpful stack trace ending in an obscure system function called misaligned_stack_error_entering_dyld_stub_binder(). It typically only shows up in opt mode, so the stack traces aren't super-helpful anyway. Speaking of stack traces, can anyone recommend a way to run the examples in the automake branch through a debugger? I should probably try export LIBMESH_OPTIONS=-on_error_attach_debugger and see if that works. > > >> Do you know how automake builds shared libraries? >> > > libtool is what takes care of this. Again, you'll see the command it uses > at link time with the --disable-silent-rules configure option. > Thanks, I will try this configure option soon... Is there any way I could try this libtool trick with the automake branch >> of libmesh as well? >> > > libtool should be doing the "trick" you showed. So are you in the > situation that trunk and branch are failing in different ways with > hand-built GCC? > No, trunk and branch fail in the same way with my hand-built GCC compiler. So I'm thinking if I can get the automake branch to do its linking the same way as trunk, I can make it work as well. > Latest automake branch is running cleanly for me (in dbg, need to try the others). > Anythign special you guys are feeding to $LIBMESH_RUN or $LIBMESH_OPTIONS? Definitely try opt mode, that's where I see the segfaults, for example in adjoints_ex1. No special LIBMESH_RUN or LIBMESH_OPTIONS, just hand-built compilers and no macports. Not sure if it was mentioned, but macports is not really an option for us since for some reason our site blocks rsync :-P > Also, did you rename the libtool executable (e.g. when macports builds autotools, it > installs libtool as glibtool), because there is a native libtool installed that's Apple's > thing and I'm not sure if glibtool is using it or not. I built libtool by hand from source (no macports on this box). I'm *definitely* not using Apple's libtool from /usr/bin! AFAICT, it doesn't even accept the same arguments as GNU libtool! Also of note: if you don't have autotools installed on your machine (which is my case for a stock Mountain Lion laptop) libmesh helpfully builds it for you, along with a libtool. So on the automake branch, I place libmesh's libtool first in my path and presumably that is the one used for linking. This may be another important difference from y'alls macports machines... -- John |
From: Roy S. <roy...@ic...> - 2012-11-08 16:38:59
|
On Thu, 8 Nov 2012, John Peterson wrote: > The error is an unhelpful stack trace ending in an obscure system > function called misaligned_stack_error_entering_dyld_stub_binder(). > > It typically only shows up in opt mode, so the stack traces aren't > super-helpful anyway. This is horrifying. I hereby apologize for ever complaining about the difficulty of debugging C++ template metaprograms. > Speaking of stack traces, can anyone recommend a way to run the > examples in the automake branch through a debugger? I should > probably try > > export LIBMESH_OPTIONS=-on_error_attach_debugger This has actually never worked for me (behavior remains as if the option was unspecified), yet it's never been a big enough deal (since -start_in_debugger always worked) for me to want to dig into. But now that the question's come up, I'm curious about whether the problem is just me, or whether other libMesh users have the same issue. Between PETSc error handlers and MPI handlers and Unix signal handlers and libMesh terminate handlers and application-specific handlers I'm not surprised if something isn't executing as planned... --- Roy |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-08 16:35:28
|
On Nov 8, 2012, at 10:21 AM, John Peterson <jwp...@gm...> wrote: > > It typically only shows up in opt mode, so the stack traces aren't super-helpful anyway. > > Speaking of stack traces, can anyone recommend a way to run the examples in the automake branch through a debugger? I should probably try > > export LIBMESH_OPTIONS=-on_error_attach_debugger > > and see if that works. >From libtool, uninstalled 'executables' are really libtool shell scripts that handle setting library paths properly. This is weird but I believe they have their reasons. So you can actually 'less' the example and see what I'm talking about… But to launch it in the debugger, do $ libtool --mode=executde gdb ./introduction-ex1 for example. (Yes, I plan to update the site documentation to contain this sort of thing before merging this.) > Definitely try opt mode, that's where I see the segfaults, for example in adjoints_ex1. No special LIBMESH_RUN or LIBMESH_OPTIONS, just hand-built compilers and no macports. Not sure if it was mentioned, but macports is not really an option for us since for some reason our site blocks rsync :-P No, you should have mentioned earlier! ;-) Mine does too - but you can set up macports to work from an svn checkout instead of rsync, which is what I do. https://trac.macports.org/wiki/howto/SyncingWithSVN My only gripe here is you need to be somewhat careful what revision you are at, because trunk is not always stable. So watch for the rREVS that correspond to releases. -Ben |
From: John P. <jwp...@gm...> - 2012-11-08 16:50:13
|
On Thu, Nov 8, 2012 at 9:34 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > But to launch it in the debugger, do > > $ libtool --mode=executde gdb ./introduction-ex1 > > for example. > Cool, this works for me. Here is the stack trace for adjoints_ex1 from the automake branch (running in opt mode). Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x00007fff948218a5 in misaligned_stack_error_entering_dyld_stub_binder () (gdb) bt #0 0x00007fff948218a5 in misaligned_stack_error_entering_dyld_stub_binder () #1 0x0000000101f3f9d0 in ?? () It's exactly the same thing I see in trunk when I don't use libtool for linking. -- John |
From: John P. <jwp...@gm...> - 2012-11-08 20:39:44
|
On Thu, Nov 8, 2012 at 9:34 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > > Definitely try opt mode, that's where I see the segfaults, for example > in adjoints_ex1. No special LIBMESH_RUN or LIBMESH_OPTIONS, just > hand-built compilers and no macports. Not sure if it was mentioned, but > macports is not really an option for us since for some reason our site > blocks rsync :-P > > No, you should have mentioned earlier! ;-) > Mine does too - but you can set up macports to work from an svn checkout > instead of rsync, which is what I do. > https://trac.macports.org/wiki/howto/SyncingWithSVN > > My only gripe here is you need to be somewhat careful what revision you > are at, because trunk is not always stable. So watch for the rREVS that > correspond to releases. Forgot to mention: our tech has tried the macports with SVN option but it also has proxy issues. We have to put: http-proxy-host = someserver http-proxy-port = 8080 in our ~/.subversion/servers file, and for some reason macports doesn't always read that file properly. We may have a decent workaround for that, though. -- John |
From: John P. <jwp...@gm...> - 2012-11-08 17:34:02
|
On Thu, Nov 8, 2012 at 9:55 AM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Any chance you can manually hack -g in there? > > ./configure libmesh_CXXFLAGS="-g" > > will do it I think... > Sure, will try that next, although I claim the stack trace will be no more illuminating ;-) And in case anyone's curious, here are the different link lines used in the automake and trunk checkouts (with some stuff removed for readability) Automake: -------- /bin/sh ./libtool \ --tag=CXX \ --mode=link \ mpicxx \ -O2 \ -felide-constructors \ -funroll-loops \ -fstrict-aliasing \ -std=c++0x \ -Wdisabled-optimization \ -fopenmp \ -o libmesh.la \ (various .lo objects) \ (various .la objects) \ -lz \ -L/opt/packages/petsc/3.3-p4/lib -lpetsc \ -L/opt/packages/hypre/2.8.0b/lib -lHYPRE \ -L/opt/packages/mpich2/mpich2-1.4.1p1/lib \ -L/opt/packages/gcc_4.6.3/lib/gcc/x86_64-apple-darwin12.0.0/4.6.3 \ -L/opt/packages/gcc_4.6.3/lib \ -lflapack -lfblas -lmpichf90 -lpthread -lgfortran \ -lquadmath -lm -lmpichcxx -lstdc++ -lpmpich -lmpich \ -lopa -lmpl -lSystem -lgcc_ext.10.5 -ldl Trunk: ------ libtool \ --tag=CXX \ --quiet \ --mode=link \ mpicxx \ -dynamiclib \ -Wl,-undefined,dynamic_lookup,-flat_namespace \ -o /Users/moose/projects/libmesh/lib/x86_64-apple-darwin12.0.0_opt/libmesh.dylib \ (various .o files) \ -Wl,-undefined,dynamic_lookup,-flat_namespace So I'd say the important differences are the following: 1.) The libtool used (trunk uses my hand-built one, automake uses one that has been generated in libmesh's top-level directory) 2.) automake branch passes more system libraries on the link line ( -lSystem, -lgcc_ext.10.5, -ldl, -lgfortran) than trunk. I guess next I'll try to have my hand-built libtool (rather than libmesh's) first in my PATH, see if that makes a difference... -- John |
From: John P. <jwp...@gm...> - 2012-11-08 18:06:29
|
On Thu, Nov 8, 2012 at 10:33 AM, John Peterson <jwp...@gm...> wrote: > Any chance you can manually hack -g in there? >> >> ./configure libmesh_CXXFLAGS="-g" >> >> will do it I think... >> > > Sure, will try that next, although I claim the stack trace will be no more > illuminating ;-) Yeah... with -g in optimized mode my stack trace looks exactly the same as without -g for this example. Let me try a debug mode build instead... is the preferred method for doing that to set the METHOD variable in the shell, or to pass it to configure as in the above example? -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-08 18:08:22
|
No preference, but the latter trumps the former. -Ben On Nov 8, 2012, at 12:06 PM, "John Peterson" <jwp...@gm...<mailto:jwp...@gm...>> wrote: On Thu, Nov 8, 2012 at 10:33 AM, John Peterson <jwp...@gm...<mailto:jwp...@gm...>> wrote: Any chance you can manually hack -g in there? ./configure libmesh_CXXFLAGS="-g" will do it I think... Sure, will try that next, although I claim the stack trace will be no more illuminating ;-) Yeah... with -g in optimized mode my stack trace looks exactly the same as without -g for this example. Let me try a debug mode build instead... is the preferred method for doing that to set the METHOD variable in the shell, or to pass it to configure as in the above example? -- John |
From: John P. <jwp...@gm...> - 2012-11-08 19:17:35
|
On Thu, Nov 8, 2012 at 11:05 AM, John Peterson <jwp...@gm...> wrote: > On Thu, Nov 8, 2012 at 10:33 AM, John Peterson <jwp...@gm...>wrote: > >> Any chance you can manually hack -g in there? >>> >>> ./configure libmesh_CXXFLAGS="-g" >>> >>> will do it I think... >>> >> >> Sure, will try that next, although I claim the stack trace will be no >> more illuminating ;-) > > > Yeah... with -g in optimized mode my stack trace looks exactly the same as > without -g for this example. Let me try a debug mode build instead... OK, so adjoints_ex1 on the automake branch works just fine in DEBUG mode. This is consistent with trunk, and what we've seen with hand-built compilers and non-libtool linking all along... so no better stack traces unfortunately. -- John |
From: Roy S. <roy...@ic...> - 2012-11-08 19:19:51
|
On Thu, 8 Nov 2012, John Peterson wrote: > OK, so adjoints_ex1 on the automake branch works just fine in DEBUG > mode. This is consistent with trunk, and what we've seen with > hand-built compilers and non-libtool linking all along... so no > better stack traces unfortunately. Have you tried setting options "in between" the opt and debug flags by hand? That's was the (successful) last hope for me when such a heisenbug hit once - try to figure out whether the breakage is due to the optimization flags or the removed libstdcxx debugging flags or what. --- Roy |
From: John P. <jwp...@gm...> - 2012-11-08 19:23:42
|
On Thu, Nov 8, 2012 at 12:17 PM, John Peterson <jwp...@gm...> wrote: > OK, so adjoints_ex1 on the automake branch works just fine in DEBUG mode. > This is consistent with trunk, and what we've seen with hand-built > compilers and non-libtool linking all along... so no better stack traces > unfortunately. Pressed "send" too soon... miscellaneous_ex6 fails in debug mode on the automake branch. (This is also consistent with what we see on trunk.) The stack trace is below. You can see that things go awry as soon as it tries to call down into a C library routine in triangle. Again, I "fixed" this on trunk by modifying triangle's Makefile to use libtool. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x00007fff948218a5 in misaligned_stack_error_entering_dyld_stub_binder () (gdb) bt #0 0x00007fff948218a5 in misaligned_stack_error_entering_dyld_stub_binder () #1 0x00007fff5fbea5d0 in ?? () #2 0x000000010169ac38 in bswpiv.1559 () #3 0x000000010090f545 in triangulate (triswitches=0x102f08448 "zBPQqpa0.010000", in=0x7fff5fbfeaa0, out=0x7fff5fbfeb50, vorout=0x0) at triangle.c:15726 #4 0x00000001005308e1 in libMesh::TriangleInterface::triangulate (this=0x7fff5fbfee90) at src/mesh/mesh_triangle_interface.C:323 #5 0x0000000100001fb3 in triangulate_domain () at miscellaneous_ex6.C:153 #6 0x0000000100001998 in main (argc=1, argv=0x7fff5fbff1c0) at miscellaneous_ex6.C:62 -- John |
From: John P. <jwp...@gm...> - 2012-11-08 19:38:54
|
On Thu, Nov 8, 2012 at 12:19 PM, Roy Stogner <roy...@ic...>wrote: > Have you tried setting options "in between" the opt and debug flags by > hand? That's was the (successful) last hope for me when such a > heisenbug hit once - try to figure out whether the breakage is due to > the optimization flags or the removed libstdcxx debugging flags or > what. > Well... on the automake branch I don't believe you get any of those libstdcxx debugging flags, even when METHOD=dbg. Here's a sample compilation line from 'make V=1': /bin/sh ./libtool \ --tag=CXX \ --mode=compile \ mpicxx -DHAVE_CONFIG_H \ -DDEBUG \ -DLIBMESH_IS_COMPILING_ITSELF \ (various -I paths) \ -O0 \ -felide-constructors \ -g \ -ansi \ -pedantic \ -W -Wall -Wextra -Wno-long-long \ -Wunused -Wpointer-arith -Wformat \ -Wparentheses -std=c++0x -Woverloaded-virtual \ -fopenmp \ -MT \ src/utils/utility.lo \ -MD -MP -MF $depbase.Tpo \ -c -o src/utils/utility.lo \ src/utils/utility.C Mostly warning stuff going on here. Any of these strike you as something to try removing? Side question: what's the right way to manually edit compiler flags on the automake branch? Looks like I can edit the generated Makefile directly... -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-08 20:14:03
|
> > Side question: what's the right way to manually edit compiler flags on the automake branch? Looks like I can edit the generated Makefile directly… Permanently or temporarily? If the latter, configure actually doesn't do anything except create config.status, which is run to create everything. You can edit config,.status directly (look for CXXFLAGS_…) and then run it: ./config.status -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-08 20:46:38
|
On Nov 8, 2012, at 2:23 PM, Roy Stogner <roy...@ic...> wrote: >> Well... on the automake branch I don't believe you get any of those libstdcxx debugging flags, even when METHOD=dbg. > > Is John correct about this? Was it an oversight or a deliberate > change? Trying to debug without the ability to turn on > bounds-checking is excruciatingly painful. > --- I think what John is observing is the flags aren't getting passed through to the link step. I can attest (as does make V=1) that they are used during compilation: libtool: compile: mpicxx -DHAVE_CONFIG_H -I. -I.. -I./include/libmesh -DDEBUG -DOMPI_SKIP_MPICXX -DMPICH_SKIP_MPICXX -DLIBMESH_IS_COMPILING_ITSELF -I../contrib/fparser -I../contrib/libHilbert/include -I../contrib/nemesis/Lib -I../contrib/exodusii/Lib/include -I../contrib/netcdf/Lib -I../contrib/gmv -I../contrib/triangle -I../contrib/tetgen -I../contrib/parmetis/include -I../contrib/metis/include -I../contrib/tecplot/include -I../contrib/gzstream -I../contrib/sfcurves -I../contrib/laspack -I/software/x86_64/boost/1.50.0-gcc-4.4/include/ -I../include -I/usr/include/glpk -I/software/x86_64/tbb/tbb41_20120718oss-gcc-4.4/include -I/software/x86_64/trilinos/10.12.2-openmpi-1.4-gcc-4.4/include -I/usr/include -I/software/x86_64/petsc/3.3-p2/include -I/software/x86_64/petsc/3.3-p2/aerolab_workstations-openmpi-1.4-gcc-4.4/include -I/software/x86_64/mpi/openmpi-1.4.4-gcc-4.4/include -I/software/x86_64/boost/1.50.0-gcc-4.4/include -I./include -O0 -felide-constructors -g -ansi -pedantic -W -Wall -Wextra -Wno-long-long -Wunused -Wpointer-arith -Wformat -Wparentheses -std=c++0x -Woverloaded-virtual -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -fopenmp -MT src/base/dof_map_constraints.lo -MD -MP -MF src/base/.deps/dof_map_constraints.Tpo -c ../src/base/dof_map_constraints.C -fPIC -DPIC -o src/base/.libs/dof_map_constraints.o -Ben |
From: John P. <pet...@cf...> - 2012-11-08 20:50:23
|
On Thu, Nov 8, 2012 at 1:46 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > I think what John is observing is the flags aren't getting passed through > to the link step. I can attest (as does make V=1) that they are used > during compilation: Nope, what I posted was from the compilation stage of utility.C. So, for whatever reason, I really don't have those pedantic flags (I'm using GCC 4.6.3 atm) but I guess you do. -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-08 21:01:47
|
On Nov 8, 2012, at 2:49 PM, John Peterson <pet...@cf...> wrote: > > > On Thu, Nov 8, 2012 at 1:46 PM, Kirk, Benjamin (JSC-EG311) <ben...@na...> wrote: > I think what John is observing is the flags aren't getting passed through to the link step. I can attest (as does make V=1) that they are used during compilation: > > Nope, what I posted was from the compilation stage of utility.C. > > So, for whatever reason, I really don't have those pedantic flags (I'm using GCC 4.6.3 atm) but I guess you do. > > -- > John ' OK, my bad. for me $ ../configure --with-method=dbg produces …. ----------------------------------- SUMMARY ----------------------------------- Package version.................... : libmesh-0.9.0 C++ compiler type.................. : gcc4.4 C++ compiler....................... : mpicxx C compiler......................... : mpicc Fortran compiler................... : mpif90 Build Method....................... : dbg CPPFLAGS........................... : -DDEBUG -DOMPI_SKIP_MPICXX -DMPICH_SKIP_MPICXX CXXFLAGS........................... : -O0 -felide-constructors -g -ansi -pedantic -W -Wall -Wextra -Wno-long-long -Wunused -Wpointer-arith -Wformat -Wparentheses -std=c++0x -Woverloaded-virtual -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -fopenmp CFLAGS............................. : -g -Wimplicit -fopenmp … with gcc4.5 Wanna show me yours? -Ben |
From: John P. <pet...@cf...> - 2012-11-08 21:25:04
|
On Thu, Nov 8, 2012 at 2:01 PM, Kirk, Benjamin (JSC-EG311) < ben...@na...> wrote: > Wanna show me yours? ----------------------------------- SUMMARY ----------------------------------- Package version.................... : libmesh-0.9.0 C++ compiler type.................. : gcc4.6 C++ compiler....................... : mpicxx C compiler......................... : mpicc Fortran compiler................... : mpif90 Build Method....................... : dbg CPPFLAGS........................... : -DDEBUG CXXFLAGS........................... : -O0 -felide-constructors -g -ansi -pedantic -W -Wall -Wextra -Wno-long-long -Wunused -Wpointer-arith -Wformat -Wparentheses -std=c++0x -Woverloaded-virtual -fopenmp CFLAGS............................. : -g -Wimplicit -fopenmp Check out compiler.m4: if test `uname` = "Darwin" ; then CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual" else CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC" fi Are you not on a Darwin system? -- John |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-08 21:39:27
|
On Nov 8, 2012, at 3:24 PM, John Peterson <pet...@cf...> wrote: > Check out compiler.m4: > > if test `uname` = "Darwin" ; then > CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual" > else > CXXFLAGS_DBG="$CXXFLAGS_DBG -std=c++0x -Woverloaded-virtual -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC" > fi Duh - that would do it. Sorry, I'm on my 5th straight hour of a phone call here. Roy, we decided to remove those flags from Darwin since they were causing unpredictable badness. Mainly I didn't want anyone freaking out that the automake branch was not doing the right thing. -Ben |