I "solved" the debugging issue:
export
DYLD_LIBRARY_PATH=/Users/gastdr/projects/libmesh/.libs:$DYLD_LIBRARY_PATH
Once again, it was not clear to me that I needed to reference .libs under
the libmesh directory... but now I can run the debug executable...
Derek
On Wed, Jan 23, 2013 at 9:16 PM, Derek Gaston <fried...@gmail.com> wrote:
> A couple of more things about the new build system when trying to make a
> new example with in-tree builds:
>
> 1. Compiling using "make check" is not a good solution:
> a. It means my Emacs hooks for compiling in Emacs don't work (small
> thing... but hacking lisp to make Emacs realize that you're in an example
> directory and to run "make check" is actually harder than you might think!)
> b. It compiles both the opt and dbg versions of the example (I can't
> seem to make it stop doing that... I tried setting METHOD and METHODS...
> but no matter what it goes with how I configured the code). I could
> reconfigure to only do one or the other, but I really need to do both on
> and off while developing.
> c. The fact that it runs run.sh every time (in both opt and debug no
> less) is annoying. Sometimes that is hanging in opt or debug mode and I
> have to stop it so I can run the debugger instead (more on this later)
>
> 2. Having to update Makefile.am and rebootstrap and reconfigure (even
> with the config.status trick) to add (or remove) any new files is
> cumbersome:
> a. If you accidentally delete the Makefile for your example you have to
> actually rerun "make" at the root level to get it recreated. This was
> definitely not clear to me (I spent a while running bootstrap, configure
> and autoconf before I figured it out)
>
> 3. The "executables" created... aren't really executables. Jed mentioned
> this but it didn't sink in. I was just trying to debug my example and for
> the life of me I couldn't figure out why this wasn't working:
>
> gdb ./example-dbg
> GNU gdb (GDB) 7.5
> ...
> "/Users/gastdr/projects/libmesh/examples/mesh_transfer/ex1_simple_dtk/example-dbg":
> not in executable format: File format not recognized
>
>
> I was so confused that (because I just installed new compilers and thought
> that maybe there was an incompatibility between the executables created by
> it and the GDB that comes with OSX) I went and downloaded the newest GDB
> source release and compiled and installed it... only to find that it didn't
> fix the problem.
>
> It wasn't until I remembered what Jed said that I actually checked the
> "executables" with the file command:
>
>
> > file example-dbg
> example-dbg: POSIX shell script text executable
>
> Ah! So I just need to go into the .libs directory to run the executable
> right?
>
> > cd .libs
> > ./example-dbg
> dyld: Library not loaded: /usr/local/lib/libmesh_dbg.0.dylib
> Referenced from:
> /Users/gastdr/projects/libmesh/examples/mesh_transfer/ex1_simple_dtk/.libs/./example-dbg
> Reason: image not found
> Trace/BPT trap: 5
>
>
> Nope. Apparently those scripts modify the environment to get all the
> right library paths into your environment (why don't the executables get
> linked with proper -r flags so that's unnecessary?).
>
> So how do I even run an example in a debugger? Well, I'm leaning towards
> modifying the automatically generated script to run "gdb ./example-dbg"...
> or writing my own little script instead.
>
>
>
> Guys... I'm still not buying this new build system. Developing in libMesh
> has definitely become much more cumbersome. It is tedious to even mess
> with libMesh now. It doesn't have any sort of "flow" during development.
> No matter what you are doing you end up "dealing with" the new system.
> Jumping in and out of thinking about the problem you are trying to solve
> and the manipulations you need to do to the build system at the moment.
>
> I know I'm stepping into "whining" territory again... but I still believe
> we took a step backward here.
>
> Derek
>
>
> On Mon, Jan 21, 2013 at 2:29 PM, John Peterson <jwpeter...@gmail.com>wrote:
>
>> On Sat, Jan 19, 2013 at 7:06 PM, John Peterson <jwpeter...@gmail.com>
>> wrote:
>> >
>> > On Jan 19, 2013, at 5:08 PM, Derek Gaston <fried...@gmail.com> wrote:
>> >
>> > On Sat, Jan 19, 2013 at 4:57 PM, Derek Gaston <fried...@gmail.com>
>> wrote:
>> >>
>> >> Hmmm.... we did some testing with this this week and there are a
>> couple of
>> >> issues:
>> >>
>> >> 1. If you don't "make install" then Make.common does not get created
>> >> (obviously not necessary for an example... but that is problematic for
>> some
>> >> users).
>> >>
>> >> 2. If you don't "make install" then bin/libmesh_config doesn't output
>> the
>> >> proper include directories (or are we doing something wrong?).
>> Coupled with
>> >> #1 this means that not make installing doesn't seem to be an option for
>> >> actual application development... but are we missing something?
>> >
>> >
>> > BTW - We didn't report these issues because when we noticed this we all
>> > agreed that we must have been remembering wrong... and that in-tree
>> builds
>> > really weren't supported. Otherwise I would have pinged you guys about
>> it.
>> >
>> > Now that I know that in-tree builds should work, I'll help work out the
>> > kinks...
>> >
>> >
>> > The "uninstalled" libmesh-config script did not print the right paths
>> for
>> > the --include switch. We immediately got build errors about not finding
>> > libmesh header files. May have something to do with the fact that we
>> are
>> > still use legacy include paths?
>>
>> So I fixed the issue I mentioned previously. Basically, with an
>> in-tree (uninstalled) build, if you still specify
>>
>> --prefix=$LIBMESH_DIR
>>
>> to configure even though you don't plan to 'make install' the library
>> there, you will get $LIBMESH_DIR/include/libmesh in your compiler
>> search paths.
>>
>>
>> This gets us a bit further, but our build next dies when it tries to
>> find the "exodusII.h" header file -- the problem is, for an installed
>> libmesh exodusII.h (and other contrib headers) get installed into
>>
>> $LIBMESH_DIR/include/libmesh
>>
>> but this doesn't happen for an uninstalled libmesh. That header is
>> still hidden away in contrib/exodusii/Lib/include where it lives in
>> the distribution.
>>
>> --
>> John
>>
>
>
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
