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