From: Hazen B. <hba...@ma...> - 2007-11-28 03:51:55
|
Alan, Any ideas about this one? It looks like several changes were made to get-drv-info and drivers/CMakeLists.txt between 5.8.0-RC1 and 5.8.0. Do you think that one of them could have led to the problems that Marius is having? thanks, -Hazen On Nov 27, 2007, at 10:19 PM, SourceForge.net wrote: > Bugs item #1834299, was opened at 2007-11-18 20:02 > Message generated for change (Comment added) made by schamschula > You can respond by visiting: > https://sourceforge.net/tracker/? > func=detail&atid=102915&aid=1834299&group_id=2915 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Marius (schamschula) > Assigned to: Nobody/Anonymous (nobody) > Summary: Build error 5.8.0 under Mac OS X > > Initial Comment: > In the configuration stage: > -- Found AQT: /Library/Frameworks/AquaTerm.framework/Headers/ > AQTAdapter.h > > In the build stage: > Scanning dependencies of target aqt > [ 46%] Building C object drivers/CMakeFiles/aqt.dir/aqt.o > Linking C shared module aqt.so > [ 46%] Built target aqt > Scanning dependencies of target get-drv-info > [ 46%] Building C object drivers/CMakeFiles/get-drv-info.dir/get- > drv-info.o > Linking C executable get-drv-info > [ 46%] Built target get-drv-info > [ 46%] Generating aqt.rc > Could not open driver module /usr/local/lib/plplot5.8.0/driversd/aqt > libltdl error: dlopen(/usr/local/lib/plplot5.8.0/driversd/aqt.so, > 9): image not found > make[2]: *** [drivers/aqt.rc] Error 1 > make[1]: *** [drivers/CMakeFiles/aqt_CHECK.dir/all] Error 2 > make: *** [all] Error 2 > > Same problem under 10.3.9, and 10.4.11. > > ---------------------------------------------------------------------- > >> Comment By: Marius (schamschula) > Date: 2007-11-27 21:19 > > Message: > Logged In: YES > user_id=1115908 > Originator: YES > > There is a reason that I build in this particular manner, i.e. in the > /tmp/plplot-x.x.x directory. When installing a pre-compiled binary > package > I can count on this path to be present. OS X dylibs have absolute > paths > inside, fixing them after the fact is a royal pain. > > I never have this problem with the standard GNU tools. This clearly > is a > cmake idiosyncrasy. > > What I don't understand, is why could I build plplot 5.7.4 and > 5.8.0-RC1, > with the same tool chain? > > As a test I just re-built 5.8.0-RC1 to make sure that the problems > were > not introduced by Xcode 2.5. No problem here. > > Obviously the problem is in the diff between 5.8.0-RC1 and 5.8.0... > > ---------------------------------------------------------------------- > > Comment By: hbabcock (hbabcock) > Date: 2007-11-27 19:18 > > Message: > Logged In: YES > user_id=1119203 > Originator: NO > > I tried a build with cmake version 2.4-patch 7 and I didn't have any > trouble, so I'm pretty puzzled. At some point I will try with g95, > but I > doubt that is the problem. > > It looks like you are building in the source directory which can > sometimes > be problematic. Did you try building in another directory, "/tmp/ > build-dir > : cmake /path/to/source/dir ..."? > > -Hazen > > > ---------------------------------------------------------------------- > > Comment By: Marius (schamschula) > Date: 2007-11-26 05:57 > > Message: > Logged In: YES > user_id=1115908 > Originator: YES > > I applied -DPLD_aqt=OFF to cmake. > > Now it dies @ > > [ 49%] Generating cairo.rc > cd /tmp/plplot-5.8.0/drivers && ./get-drv-info cairo > > /tmp/plplot-5.8.0/drivers/cairo.rc > Could not open driver module /usr/local/lib/plplot5.8.0/driversd/cairo > libltdl error: dlopen(/usr/local/lib/plplot5.8.0/driversd/cairo.so, > 9): > image not found > make[2]: *** [drivers/cairo.rc] Error 1 > make[1]: *** [drivers/CMakeFiles/cairo_CHECK.dir/all] Error 2 > make: *** [all] Error 2 > > Same problem. > > Why is it looking for a directory that is yet to be installed? > After all, > /usr/local/lib/plplot5.8.0/driversd/ will only be created at > install time. > > Note: /tmp/plplot-5.8.0/drivers/cairo.so does exist. > >> On 10.4 I don't think you need the "-single_module" FFLAGS & FCFLAGS. > > I haven't specified any of these by hand. > > ---------------------------------------------------------------------- > > Comment By: hbabcock (hbabcock) > Date: 2007-11-25 11:37 > > Message: > Logged In: YES > user_id=1119203 > Originator: NO > > -DPLD_aqt=OFF will turn off the aqt driver. I'm not really sure how > you > get cmake help. I usually use ccmake to toggle the various build > options. > > On 10.4 I don't think you need the "-single_module" FFLAGS & FCFLAGS. > Though I don't think that is the problem since I didn't have any > trouble > when I used them. > > We have identical XCode and gcc, but I'm using gfortran and cmake > 2.4-patch 5. There is a message in the PLplot dev list about cmake > 2.4.7 > having a showstopper bug. See "[Plplot-devel] CMake 2.4.7 RC 10 has a > showstopper bug" from Alan Irwin on June 6, 2007. Maybe this is the > problem? Not sure why it would have worked before though. > > -Hazen > > > ---------------------------------------------------------------------- > > Comment By: Marius (schamschula) > Date: 2007-11-22 10:28 > > Message: > Logged In: YES > user_id=1115908 > Originator: YES > > On the 10.4.11 machines, I've got Xcode 2.5. More specifically on > the PPC > box: > > gcc --version > powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. > build > 5370) > Copyright (C) 2005 Free Software Foundation, Inc. > > g95 --version > G95 (GCC 4.0.3 (g95 0.91!) Oct 18 2006) > Copyright (C) 2002-2005 Free Software Foundation, Inc. > This one is a little out of date, but I have no problems building with > this version. The Intel box has a newer version, The 10.3.9 box > uses g77. > > cmake --version > cmake version 2.4-patch 7 > > Given that I remain a noob wrt cmake (this is the only package of > > 350 > that I build on a regular basis, that I need cmake for) I have no > clue how > to pass a configure argument to turn off the aqt. What is the the > cmake > equicvalent of configure --help? > > ---------------------------------------------------------------------- > > Comment By: hbabcock (hbabcock) > Date: 2007-11-22 10:17 > > Message: > Logged In: YES > user_id=1119203 > Originator: NO > > Also, in the /tmp/plplot-5.8.0/drivers/ folder do you have a aqt.so > file? > It looks to me like the problem is that the aqt.so file is not being > created, then the program get-drv-info can't find it so it falls > back to > looking in /usr/local/lib/plplot5.8.0/driversd/ where of course it > also > doesn't exist. > > -Hazen > > > ---------------------------------------------------------------------- > > Comment By: hbabcock (hbabcock) > Date: 2007-11-22 10:07 > > Message: > Logged In: YES > user_id=1119203 > Originator: NO > > If you turn off the aqt driver does it build successfully? > Which version of XCode do you have installed? Which version of g95? > cmake > version? > > -Hazen > > > ---------------------------------------------------------------------- > > Comment By: Marius (schamschula) > Date: 2007-11-22 06:29 > > Message: > Logged In: YES > user_id=1115908 > Originator: YES > > The first statement is correct, but to be more precise: > > The builds worked for 5.8.0-RC1. > > Indeed. I'm installing into /usr/local. > > I've attached the cmake and make VERBOSE=1 output. > File Added: plplot5.8.0verbose.txt > > ---------------------------------------------------------------------- > > Comment By: hbabcock (hbabcock) > Date: 2007-11-21 23:49 > > Message: > Logged In: YES > user_id=1119203 > Originator: NO > > I assume that you did not have this problem with 5.7.4? > Are you doing a standard install (i.e. into /usr/local/)? > Could you try again with using "make VERBOSE=1"? > > It is puzzling that it is trying to open the installed driver > module at > this stage. This driver module would not even exist until after the > installation had been successful. > > -Hazen > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/? > func=detail&atid=102915&aid=1834299&group_id=2915 |
From: Alan W. I. <ir...@be...> - 2007-11-28 05:34:42
|
On 2007-11-27 22:49-0500 Hazen Babcock wrote: > > Alan, > > Any ideas about this one? It looks like several changes were made to > get-drv-info and drivers/CMakeLists.txt between 5.8.0-RC1 and 5.8.0. Do you > think that one of them could have led to the problems that Marius is having? > > thanks, > -Hazen Hi Hazen: Yes, we did make changes in that area, and, yes, it is possible it is causing trouble in certain special cases (just like the old method was also causing trouble in certain special cases). The fundamental issue is you have nominally the same platform, but you cannot reproduce this bug. Nevertheless, I would take it seriously since it most likely is a real bug, for Marius's particular build methods, tool chain, and platform. There is a real art to debugging build problems remotely, but you are lucky here that you have a similar platform to Marius. I suggest you try to mimic Marius's exact build method (cmake options including an in-source build if that is what he did) and tool chain (e.g., cmake version) as much as possible. Get him to tell you his exact cmake options and give you the cmake.out and make.out from a clean build, and compare it with yours. Try his exact cmake options yourself. Make sure you have the same version of the libltdl library that he does, etc. Get Marius to execute get-drv-info in several different experimental ways, and you do the same. Does any of this "art" sound familiar? :-) Good luck getting this sorted out. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Hazen B. <hba...@ma...> - 2007-12-03 01:18:07
|
On Nov 28, 2007, at 12:34 AM, Alan W. Irwin wrote: > On 2007-11-27 22:49-0500 Hazen Babcock wrote: > >> >> Alan, >> >> Any ideas about this one? It looks like several changes were made to >> get-drv-info and drivers/CMakeLists.txt between 5.8.0-RC1 and >> 5.8.0. Do you >> think that one of them could have led to the problems that Marius >> is having? > > There is a real art to debugging build problems remotely, but you > are lucky > here that you have a similar platform to Marius. I suggest you try > to mimic > Marius's exact build method (cmake options including an in-source > build if > that is what he did) and tool chain (e.g., cmake version) as much as > possible. Get him to tell you his exact cmake options and give you the > cmake.out and make.out from a clean build, and compare it with > yours. Try > his exact cmake options yourself. Make sure you have the same > version of the > libltdl library that he does, etc. Get Marius to execute get-drv-info > in several different experimental ways, and you do the same. We did have a different version of libtool but I switched to the same version and I still do not see this problem. It looks to me like get- drv-info is confused on Marius's platform and is looking for the drivers in the install directory rather than in the build directory. The source of the confusion seems to be plGetDrvDir() returning the wrong directory, likely because (1) it is in turn misled by plInBuildTree() or (2) the BUILD_DIR environment variable is set incorrectly. This would be easier to sort out if there was a flag for debugging output from pldebug() during the build. Is there such a thing? -Hazen |
From: Andrew R. <and...@us...> - 2007-12-03 08:16:48
|
On Sun, Dec 02, 2007 at 08:15:20PM -0500, Hazen Babcock wrote: > > On Nov 28, 2007, at 12:34 AM, Alan W. Irwin wrote: > > > There is a real art to debugging build problems remotely, but you > > are lucky > > here that you have a similar platform to Marius. I suggest you try > > to mimic > > Marius's exact build method (cmake options including an in-source > > build if > > that is what he did) and tool chain (e.g., cmake version) as much as > > possible. Get him to tell you his exact cmake options and give you the > > cmake.out and make.out from a clean build, and compare it with > > yours. Try > > his exact cmake options yourself. Make sure you have the same > > version of the > > libltdl library that he does, etc. Get Marius to execute get-drv-info > > in several different experimental ways, and you do the same. > > We did have a different version of libtool but I switched to the same > version and I still do not see this problem. It looks to me like get- > drv-info is confused on Marius's platform and is looking for the > drivers in the install directory rather than in the build directory. > The source of the confusion seems to be plGetDrvDir() returning the > wrong directory, likely because (1) it is in turn misled by > plInBuildTree() or (2) the BUILD_DIR environment variable is set > incorrectly. This would be easier to sort out if there was a flag for > debugging output from pldebug() during the build. Is there such a thing? Just a thought. Not sure if this is relevant on MacOS, but I have had trouble on Linux when the build tree contains symlinks. getcwd returns the absolute directory path, whereas cmake stores the directory path you have cd'd to, which may contain symlinks. Took me a while to track this one down. Andrew |
From: Andrew R. <and...@us...> - 2007-12-03 11:49:41
|
On Mon, Dec 03, 2007 at 08:16:17AM +0000, Andrew Ross wrote: > On Sun, Dec 02, 2007 at 08:15:20PM -0500, Hazen Babcock wrote: > > > > We did have a different version of libtool but I switched to the same > > version and I still do not see this problem. It looks to me like get- > > drv-info is confused on Marius's platform and is looking for the > > drivers in the install directory rather than in the build directory. > > The source of the confusion seems to be plGetDrvDir() returning the > > wrong directory, likely because (1) it is in turn misled by > > plInBuildTree() or (2) the BUILD_DIR environment variable is set > > incorrectly. This would be easier to sort out if there was a flag for > > debugging output from pldebug() during the build. Is there such a thing? > > Just a thought. Not sure if this is relevant on MacOS, but I have had > trouble on Linux when the build tree contains symlinks. getcwd returns > the absolute directory path, whereas cmake stores the directory path you > have cd'd to, which may contain symlinks. > > Took me a while to track this one down. I've finally got round to tackling this problem and commited a patch to SVN to solve the symlink issues with BUILD_DIR. You might like to test this and see if it solves your problems. Andrew |