On Fri, May 30, 2008 at 12:06 PM, Roy Stogner <[EMAIL PROTECTED]> wrote: > > On Fri, 30 May 2008, Dmitry Matison wrote: > >> I'm using libmesh via cygwin and have a problem with configure procedure. >> Have someone handled with these errors? >> >> checking dlfcn.h usability... no >>> checking dlfcn.h presence... yes >>> configure: WARNING: dlfcn.h: present but cannot be compiled >>> configure: WARNING: dlfcn.h: check for missing prerequisite headers? >>> configure: WARNING: dlfcn.h: see the Autoconf documentation >>> configure: WARNING: dlfcn.h: section "Present But Cannot Be Compiled" >>> configure: WARNING: dlfcn.h: proceeding with the preprocessor's result >>> configure: WARNING: dlfcn.h: in the future, the compiler will take >>> precedence >>> configure: WARNING: ## ------------------------------------------ ## >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >>> configure: WARNING: ## ------------------------------------------ ## >>> checking for dlfcn.h... yes > > If configure doesn't find a workable dlfcn.h header, it shouldn't > matter for most users - "print_trace()" support will be turned off, > but that's just an internal utility function that makes parallel > debugging on Linux a bit easier. I'm not *too* surprised if the > underlying functions aren't fully supported by cygwin. > >>> checking rpc/rpc.h usability... no >>> checking rpc/rpc.h presence... yes >>> configure: WARNING: rpc/rpc.h: present but cannot be compiled >>> configure: WARNING: rpc/rpc.h: check for missing prerequisite headers? >>> configure: WARNING: rpc/rpc.h: see the Autoconf documentation >>> configure: WARNING: rpc/rpc.h: section "Present But Cannot Be Compiled" >>> configure: WARNING: rpc/rpc.h: proceeding with the preprocessor's result >>> configure: WARNING: rpc/rpc.h: in the future, the compiler will take >>> precedence >>> configure: WARNING: ## ------------------------------------------ ## >>> configure: WARNING: ## Report this to the AC_PACKAGE_NAME lists. ## >>> configure: WARNING: ## ------------------------------------------ ## >>> checking for rpc/rpc.h... yes >>> checking for xdrstdio_create... no > > This is more annoying (lack of a good rpc.h header means .xdr file > support will be disabled!), but until you figure out why configure > doesn't think your rpc.h header works, you can always use .xda files > instead; they're just the ASCII version of the same format. > >> Another problem is that I can't run the examples because of these errors: >> >> $ ./ex0-opt.exe >>> [0] /cygdrive/d/projects/vs/libmesh-0.6.2/include/numerics/type_vector.h, >>> line 389, compiled May 29 >>> 2008 at 18:30:27 >>> Aborted (core dumped) > > This is an unrelated problem. Take a look at line 389 of > type_vector.h; it's basically complaining that some code is trying to > access the z coordinate of a space vector when the library's been > compiled to use two spatial dimensions. If you've set DIM to > something other than 3 (e.g. by editing libmesh_common.h, or > configuring with --enable-2D-only), then set it back for now, and > we'll try to replicate and fix the problem before the next release. > If you haven't set DIM to something other than 3 intentionally, then > there must be some other definition of DIM coming in through cygwin or > other third party headers; I'm not sure what the best way to quickly > fix that would be.
Ooops, Roy was a bit faster than me... > In the long run: Ben, John, should we switch that preprocessor > variable name to "LIBMESH_DIM"? Even if it's not conflicting with > someone else's names now, it's such a short natural name that it's > bound to conflict with something else eventually. Sounds like a good plan, along the lines of your changes of error() -> libmesh_error(), etc. While we're at it, should we also consider similar changes for the other #defines in libmesh_config.h? For example, all the HAVE_LIBRARYFOO would become LIBMESH_HAVE_LIBRARYFOO, etc. Granted, these are less likely than DIM to trip over other libraries but as the library gets more mature I think this is a natural progression... -J ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
