From: Amitha P. <pe...@cs...> - 2002-05-20 20:35:32
|
[Moved thread to vxl-maintainers.] On Mon, May 20, 2002 at 01:46:00PM -0400, Wheeler, Fred (Research) wrote: > Does anybody else care about compiling VXL in cygwin with gcc? I think that is a useful platform/compiler combination to support. Perhaps you could submit a nightly build to the dashboard? :-) > For a shared library build with gcc 2.95.3-5 (cmake > -DBUILD_SHARED_LIBS:BOOL=OFF), only 20 libraries (DLLs) got built. > I only looked closely at the errors for testlib.dll, which did not > get built. It did not build because of an undefined reference to > "register_tests()". Perhaps the link line is not issued properly in > this environment? AFAIK, vxl currently cannot be build into DLLs. From some conversations I've had with Bill Hoffman and Brad King, it seems that Windows DLLs require full dependency information for each library in order to build an executable. The CMakeListsLink.txt hack we have provides the dependency information to the executables but not to the library. Also, building DLLs under windows requires all sorts of "DLL export" stuff--stuff that I know very little about. However, Brad mentioned that he had some simple modification to our instantiation macros that may permit DLLs. We could incorporate that if there was a desire to build Windows DLLs. As I do not work with Windows much, I am hesistant to take lead. Also, I suggest that we wait for CMake 1.4 before starting this sort of change. CMake 1.4 will support dependency analysis, which means that all our CMakeListsLink.txt hack can go away, and our link lines will become much shorter. CMake 1.4 will be released "any day now". (The release date was about 3 weeks ago. I then broke the CMake build, and took about a week to fix. I don't know what the current status is.) > I can't get the gui stuff to compile with gcc. VGUI seems to require > a flavor of mesa different than that provided with Cygwin (XFree86). > Cygwin has no xmesa.h, just osmesa.h. This is a problem with FreeBSD and Linux platforms too. Unfortunately, if you disable the MESA (xmesa.h) based acceleration, then overlay emulation becomes *very* slow. Overlays are used mostly--only?--for rubberbanding. It may be useful to have a slow but working version, though. > Under Cygwin, gcc is picky about the order of libraries at link > time. gcc's info pages imply that this is always the case for gcc, > but I have not seen the problem with gcc/binutils under Solaris. Most new platforms doesn't have a problem with link library order with gcc/GNU ld. However, the CMakeListsLink.txt should ensure that the libraries are always put in the correct order. Can you be more specific about where things are failing? > If all of the vgui stuff only built when HAS_OPENGL is true, then > cygwin/gcc would compile cleanly, though incompletely. This is as should be. I gather you've made appropriate changes to fix the broken ones. Thanks. Amitha. |
From: Wheeler, F. (Research) <wh...@cr...> - 2002-05-22 18:36:27
|
Amitha, > I think that is a useful platform/compiler combination to > support. Perhaps you could submit a nightly build to the dashboard? > :-) I'm using cygwin on a laptop right now so it would not be very practical to do a nightly dashboard build. > Most new platforms doesn't have a problem with link library order with > gcc/GNU ld. However, the CMakeListsLink.txt should ensure that the > libraries are always put in the correct order. Can you be more > specific about where things are failing? I was getting failures in many places, basically, anywhere where the link line had an -lzlib before -lpng and not after (or any other dependent pair in the wrong order). Your recent cmake fix solved the problem with the non-v3p libs that are added in with CMakeListsLink files, but I'm still fixing the problem with the vxl/v3p libs. The problem I'm having with v3p is that VXL CMakeLists.txt files add the v3p libs by including modules like Modules/FindPNG.txt. These modules are set up to do the following, if the library has not yet been found try to find the library if the library is found set HAS_XXX and other PATH vars include headers and library file The problem above is that the library will be added to the link line only once. To fix this I'm changing Modules to do the following. Replace XXX with X11, or OPENGL, or whatever. if the user has not explicitly set FIND_XXX to false if the library has not yet been found (HAS_XXX not set) try to find the library if the library is found set HAS_XXX and other PATH vars if HAS_XXX include headers and library file The use of FIND_XXX gives the user the ability to tell cmake not to try to find XXX. The user can then leave it disabled, or tell cmake where it is by setting HAS_XXX, XXX_INCLUDE_PATH, etc. in the cache file or on the command line. The first stanza above is used only the first time the module is included, if the library is found, like the current modules work. The second stanza is used every time the module is included if the libraries are available. There is some additional trickery for libraries like PNG where the is the choice of a native or vxl/v3p version. I am using a FIND_NATIVE_XXX option to disable looking for a native version and the force the use of vxl/v3p/xxx. This is a major change, so I plan to get this working for myself and then send one of the module files to vxl-maintainers for review before I commit. How does this jive with the new library features of cmake 1.4? > > > If all of the vgui stuff only built when HAS_OPENGL is true, then > > cygwin/gcc would compile cleanly, though incompletely. > > This is as should be. I gather you've made appropriate changes to fix > the broken ones. Thanks. I'm working on fixing these, but am breaking at least as much as I fix. Once I think I have things in order I'll write an explanation to the vxl-maintainers list as to what I have done and look for consensus (or hope for silence, and assume consensus). For cygwin I'm having to fix problems like: just because you are WIN32 does not mean you can use MFC. Under cygwin, cmake sets WIN32, UNIX, and CYGWIN. Fun fun. |
From: Amitha P. <pe...@cs...> - 2002-05-22 22:18:14
|
> How does this jive with the new library features of cmake 1.4? I think things will be *much* easier with CMake 1.4. With the dependency analysis, we will not need the CMakeListsLink.txt, which is the cause of the problem. Here's how I see some of the CMakeLists.txt with CMake 1.4: FindXXX: same as the current, except all the LINK_LIBRARIES( YYY ) will be replaced by SET( XXX_LIBS YYY ). With 1.4, YYY could be a list of libraries. With this change, a FindXXX will never cause a library to be linked. It'll just set a variable for the caller to use as it sees fit. vil/CMakeLists.txt: INCLUDE( FindPNG.cmake ) SET( vil_SOURCES file1.h file1.cxx ... ) IF( HAS_PNG ) INCLUDE_DIRECTORIES( ${PNG_INCLUDES} ) SET( vil_SOURCES ${vil_SOURCES} ... ) ENDIF( HAS_PNG ) ADD_LIBRARY( vil ${vil_SOURCES} ) # vil depends on vcl TARGET_LINK_LIBRARIES( vil vcl ) IF( HAS_PNG ) TARGET_LINK_LIBRARIES( vil ${PNG_LIBS} ) ENDIF( HAS_PNG ) my_executable/CMakeLists.txt ADD_EXECUTABLE( my_prog my source files ... ) # my prog only uses vil directly TARGET_LINK_LIBRARIES( my_prog vil ) When processing my_executable/CMakeLists.txt, CMake will automatically pull in the dependencies of vil and add them to the link line *a correct order*. ("a" because there may be more than one "correct" order.) There are no more CMakeListsLink.txt files to capture the dependencies; the TARGET_LINK_LIBRARIES will cause CMake to write the dependency information into the cache and manage it for us. Amitha. |