Conversation
It embeds RPATH to $ARTIFACT/lib, that way the proper libstdc++ and libgcc will be used.
|
Useful. I don't see a reason not to merge this in. |
Add a comment.
|
I've moved the line to a better location in the file and added a comment. |
|
Don't merge this yet, it doesn't seem to be working for building hashstack. I am investigating. |
|
So any package that uses libtool and C++ fails, it looks like the shared library is not created, but I haven't figured it out yet. CMake packages build just fine, also if I build things by hand, it works as well. Boost builds too. |
|
libtool and C++, curious can you send me some logs privately (or on the list) to dissect? I have several gcc that are patched as discussed (instead of this) and I have never had that problem. |
|
After lots of debugging of the gmp package, I found out the problem: First it fails, then I change at the bottom of the (generated) to Note that the Then it works. So now the next step is to figure out how to make sure hardcode_action is set to |
|
I have verified that with a working configuration (no PROLOGUE in the profile), the hardcode check is there twice in configure: Which causes the CXX part in |
|
I think the C++ tests were skipped due to these lines in # No sense in running all these tests if we already determined that
# the CXX compiler isn't working. Some variables (like enable_shared)
# are currently assumed to apply to all compilers on this platform,
# and will be corrupted by setting them based on a non-working compiler.
if test "$_lt_caught_CXX_error" != yes; then
...Somehow |
|
You have naked "-rpath" in those libtool lines. i.e. they are not preceded by "-Wl,", they are supposed to be passed directly to ld, they wouldn't work for gcc or g++ (or gfortran for that matter). I would need to check the configure script. You say it is gmp, is it actually mpir? |
|
Hadn´t seen your comment about |
|
Ok, I think I found the problem. In the if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
(test "X$CXX" != "Xg++"))) ; thentest that the to this: |
|
My goodness it is trying to compile instead of just giving you g++ info. What about |
|
I see, it's the extra options being passed to the linker that are causing this, e.g. using the systemwide compiler: Looks like the extra configure option causes g++ to go via a different route, which then confuses the |
|
I don't have this problem at all with the patched version |
|
I will be honest and call this a gcc bug. But did you read the rest of the thread where we turned more to wrapping the system |
|
The following patch to --- a/configure
+++ b/configure
@@ -18755,7 +18755,7 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
CC="$lt_save_CC"
if test -n "$CXX" && ( test "X$CXX" != "Xno" &&
- ( (test "X$CXX" = "Xg++" && `g++ -v >/dev/null 2>&1` ) ||
+ ( (test "X$CXX" = "Xg++" && `g++ --version >/dev/null 2>&1` ) ||
(test "X$CXX" != "Xg++"))) ; then
ac_ext=cpp
ac_cpp='$CXXCPP $CPPFLAGS'So that shows where the problem is. Essentially Since otherwise things work, we should figure out how to patch g++ to return 0 exit code for |
|
Similar difference is for |
|
On Wed, Feb 18, 2015 at 5:33 PM, Ondřej Čertík notifications@github.com
|
|
@kiwifb --- I also think it's a bug in gcc. I noticed that the If we go the patching route, it would be patched in the set_collect_gcc_options() function in I think it's hackish though, and since the spec modification doesn't have this problem, I would go that route. @kiwifb do you think you could send me a patch how you think it should be modified? You don't need to test it, I'll test it myself. I am a little at loss of which variables should be modified. Essentially the spec that needs to got there is just |
|
rs6000 is ppc specific you want to spray all the subfolder of gcc/config containing linux.h/linux64.h/sysv4.h files. LFS style: http://www.linuxfromscratch.org/lfs/view/stable/chapter05/gcc-pass1.html I don't suggest you follow what LFS does as it wouldn't work in your case. Before I go further writing a sed line I need to know if gcc is built multilib and if not if you put everything under lib or lib64. |
|
It appears you are not multilib and you put things into "lib" I'll get to that after lunch. |
|
@kiwifb correct, no multilib, and I put (link) everything into |
|
Hum.... I actually learned something new today. The structure is not strictly the same across architectures, a generic sed won't do. I guess if it had been as simple as I was thinking it would have been refactored already. Not impossible it will all be streamlined and refactored in the future. There is a lot of common things across several archs here but it is coded slightly differently in each one. |
|
I will target linux x86(_64) first what archs are we targeting? |
|
Yes, just send a patch for x86(_64). After we test it and it works, we can add support for 32 bits, that should cover most Linux + Mac machines, wouldn't it @ahmadia? We can implement support for more later. |
|
No darwin won't be covered, I don't know where to poke for darwin, I have been looking on and off for sometimes, I'll try to follow a new lead now. |
|
Ok. Let's concentrate on x86_64 for now, as that I can test and use daily. We can add the rest later. |
where |
|
I think I now have a clue for darwin - I know which file needs patching (gcc/config/darwin.h). Where to put the line is the hard bit because it looks very different from linux. |
This is gcc/config/darwin.h as before @@artifact@@ would have to be filled with the right value. This is also to be tested. |
|
Ate my own dog food on x86_64 with the kind of configuration used by hashdist and my patch I'll have a look at OS X later. |
|
On Wed, Feb 18, 2015 at 9:49 PM, François Bissey notifications@github.com
Sweet! |
|
It works!!! |
|
I am closing this in favor of #646. |
3 participants
It embeds RPATH to $ARTIFACT/lib, that way the proper libstdc++ and libgcc will
be used.
Here is "proof" that it works: