-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
scon failure at boost stage #126
Comments
Ooops, I deleted a comment then that was mostly nonsense due to a complete misreading of the message. Sorry Dave! (and @TallJimbo ) Alas, my misreading also means that now I have far less idea what the problem might be here, and so I throw the Issue out to the general populace. We are always keen to get more possible build scenarios under our belt. Would it be possible to post the whole (or at least a chunk around the interesting bits of) the config.log file? |
It'd be most helpful if you could: This failure actually seems familiar, but I can't remember what the problem was last time we saw it (and if it was identical, I'd think we'd have fixed the unhelpful error message). But I am concerned a little about the gcc version; Barney, do you know if we have any confirmed successes with Apple's gcc 4.0? It might be good to start compiling a matrix of platforms / dependency versions we know we've got things working on. |
Can do. Here you go. Incidentally, I compiled successfully on my home machine, same OS, same versions of the various libraries, same procedure. Thanks. Dave file /Users/goldberg/Downloads/GalSim-developers-GalSim-edd5d8e/SConstruct,line 997: scons: Configure: Checking for C++ library fftw3... scons: Configure: Checking for C++ header file boost/shared_ptr.hpp... scons: Configure: Checking for C++ header file TMV.h... scons: Configure: Checking for correct TMV linkage... scons: Configure: Checking if we can build against Python... scons: Configure: Checking if we can build against NumPy... scons: Configure: Checking if we can build against Boost.Python... |
Here's what I can tell so far:
When that's happened in the past, it's sometimes been because the version of some library (probably python2.x or boost_python) found by the runtime linker system (e.g. LD_LIBRARY_PATH) is different from the version picked up by the gcc linker (via -L options), so the versions of the two libraries weren't compatible at runtime. Do you have two versions of Python or Boost on your system? If you're comfortable running I've also just opened a new issue (#127) to try to revamp how we do these configure checks; if we can't make progress here, that might give us something else to try. |
My general policy is to always try the configuration "as is" before trying to add other things, as you say, expecting it to fail most of the time. The reason for it is in case people add explicit libraries with the EXTRA_LIBS option. If you have a non-standard set up, then you might need to just explicitly tell SCons what to use. In that case, we want to use those libraries rather than the ones that we think should work for normal set ups. Maybe this isn't really necessary, but I don't think it's a huge time sink to do it that way. |
Also, Dave, do a git pull and rerun scons. I'd had it set to remove the .scon* files to make sure they get remade after an error, but that means they're not around to diagnose problems. So I removed that "feature" (bug). |
In reply to @TallJimbo, no I don't recall a successful case with gcc4.0. A table of successful/failed build cases is an excellent idea, I'll get working on a spreadsheet we can all share... |
I just tested with g++ 4.0.1 and it worked fine, so I don't think that's the problem. The only compiler that I've tried which I haven't fully gotten everything to work yet is icpc. It fails to find some stuff at run time when trying to load the galsim library. I think I got it to work by setting LD_LIBRARY_PATH, but that's an inelegant solution. I didn't make an issue for it, but I guess I probably should. It's not the machine I usually use, so it hasn't been high priority for me, and I don't think anyone else is using icpc. |
I spoke too soon. Turns out scons tests failed for 4.0, but I just fixed it. Dave, another thing that could possibly be the problem is that on my computer the g++-4.0 compiler defaults to compiling 32 bit code, and the python version that comes with the computer is 64 bit, and thus needs 64 bit libraries. If this is true on your computer too, then that could possibly be the problem. (Although for whatever reason, the clash didn't show up on my computer until I ran scons tests, so maybe not.) Anyway, to check this you could try running:
and see if that works. |
At Mike's suggestion, I checked out the latest version of of GalSim (GalSim-developers-GalSim-5088ebd.tar). The previous version (GalSim-developers-GalSim-edd5d8e.tar) did not save the .sconf_temp/ directory. However, now I find that my build fails even earlier, at the TMV stage. I have tried manually including a TMV_DIR flag, but that doesn't seem to be the issue. I should note that I use gcc 4.0.1 both at work and at home (where I compiled successfully). My current log is below. Thoughts and suggestions are, of course, appreciated. Dave file /Users/goldberg/Desktop/GalSim-developers-GalSim-5088ebd/SConstruct,line 1003: scons: Configure: Checking for C++ library fftw3... scons: Configure: Checking for C++ header file boost/shared_ptr.hpp... scons: Configure: Checking for C++ header file TMV.h... scons: Configure: Checking for correct TMV linkage... |
Well, to get the TMV stuff to work, you'd want to do the same thing (scons I did find a tricky way to check if your python is running as a 32- or 64-bit application. Type in the command line:
And post what it says. (Specifically, we're looking for how many f's there are.) |
There are 7: But I believe that my machine at home (which successfully compiled and Dave On 4/30/12 1:13 PM, Mike Jarvis wrote:
Dave Goldberg, Ph.D. |
Yes. 32 bit. So that means my -m64 idea won't work. You should remove it either by removing the line from gs_scons.conf or running But that also means we're back to square one. So please run scons again, which should now get past the TMV stuff and probably fail at the same place it originally failed. Then post the output of the last .out file that scons makes. (It will probably still be .sconf_temp/conftest_11.out as it was in your earlier config.log output.) Maybe that will provide a clue. You can also run .sconf_temp/conftest_11 directly on the command line as see what the output is directly. Sometimes it is more helpful to run it that way. And as Jim suggested, if you can run it through gdb and get a backtrace, that would be helpful too. |
Just an FYI, the line needs to be removed by hand. For some reason, But at any rate, it worked, sort of. The problem is that I still get Dave On 4/30/12 1:32 PM, Mike Jarvis wrote:
Dave Goldberg, Ph.D. |
Thanks for the update. I don't know that I'll be able to make much progress on this until I've tried to implement #127, and even that is a bit of a shot in the dark. And unfortunately, I'm traveling this week and won't have much time to put into that. Hopefully this isn't too much of a blocker for you. |
Ah. Because I mistyped. It should have been Anyway, can you try the following now:
|
Rather than send you the (extremely lengthy) output, below is the post arning: Could not find object file ..... done Program received signal EXC_BAD_ACCESS, Could not access memory. On 4/30/12 1:47 PM, Mike Jarvis wrote:
Dave Goldberg, Ph.D. |
Wow. You managed to find a bug in gdb. That's always fun. I'm afraid I don't know what to try next. It doesn't look like an LD_LIBRARY_PATH problem. But just for grins, can you post what |
One little red flag (which may be a red herring) is the mention of "libpython2.7.a" at the top of that gdb output. If we're somehow linking against a static library instead of a shared library, that could be responsible. Do you have a |
I checked and: Mike, I don't currently have my LD_LIBRARY_PATH variable set, but my otool yields: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation Hmm.... Dave On 4/30/12 2:25 PM, Jim Bosch wrote:
Dave Goldberg, Ph.D. |
Looking through your config.log and the otool output, my best guess is that you have either a boost, numpy or python library in /opt/local/lib that is linking with the python library in /opt/local/Library.../Python. And since you told SCons to look there for fftw3, the linking step finds the wrong whatever library there as well. So my recommendation is to install your fftw3 stuff in a different directory so that SCons doesn't have to look in /opt/local/lib. e.g. just copy the fftw3 header files and libraries into the normal /usr/local/lib. Then you can remove the FFTW_DIR line from your gs_scons.conf file and see if that helps. |
Outstanding. We're all good now. Thanks for all of your help. Dave On 5/6/12 11:10 PM, Mike Jarvis wrote:
Dave Goldberg, Ph.D. |
Good. I'll close this issue then. Not sure if there's anything to pull out of here to put in the Install FAQ. It's probably a fairly particular issue for your setup, but if you can think of something that you might have wanted to read there to help you figure out the problem, please feel free to add an entry about this. |
Greetings, all. I haven't seen this problem yet, but hopefully it has an easy fix. I am compiling GalSim on a Mac (10.5.8) using Python 2.7. I installed Boost from source, and tested afterwards with:
otool -L /usr/local/lib/libboost_python.dylib
/usr/local/lib/libboost_python.dylib:
libboost_python.dylib (compatibility version 0.0.0, current version 0.0.0)
/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
which I interpret as a good thing.
However, upon running:
I get:
scons: Reading SConscript files ...
SCons is version 2.1.0 using python version 2.7.1
Python is from /Library/Frameworks/Python.framework/Versions/2.7/include/python2.7
Using compiler: /usr/bin/g++
compiler version: 4.0.1
Determined that a good number of jobs = 2
Checking for C++ library cfitsio... yes
Checking for C++ library fftw3... yes
Checking for C++ header file boost/shared_ptr.hpp... yes
Checking for C++ header file TMV.h... yes
Using TMV_LINK file: /usr/local/share/tmv/tmv-link
-ltmv -lblas
Checking for correct TMV linkage... (this may take a little while)
Checking for correct TMV linkage... yes
Checking if we can build against Python... yes
Checking if we can build against NumPy... yes
sh: line 1: 40620 Bus error .sconf_temp/conftest_11 > ".sconf_temp/conftest_11.out"
Checking if we can build against Boost.Python... no
Cannot run program built with Boost.Python.
Please fix the above error(s) and rerun scons
which doesn't seem terribly helpful. The bus error is particularly confusing.
I've looked in the config.log file, and while there are a few hints, I'm not sure what to make of them. In particular:
boost::python::converter::as_to_python_function<Foo, boost::python::objects::class_cref_wrapper<Foo, boost::python::objects::make_instance<Foo, boost::python::objects::value_holder > > >::convert(void const*)in conftest_9.o
ld: symbol(s) not found
Though as I'm not an expert in boost, I've no idea what to make of this.
Any suggestions?
Thanks,
Dave
The text was updated successfully, but these errors were encountered: