Error in libs/regex/build/gcc-shared.mak (current cvs)
ICU_LDFLAGS= -L$(ICU_PATH)/lib This is wrong. On x86_64, the path is .../lib64. Can we maybe find a better way to do this?
Neal Becker wrote:
ICU_LDFLAGS= -L$(ICU_PATH)/lib
This is wrong. On x86_64, the path is .../lib64.
Can we maybe find a better way to do this?
For Boost 1.33.0 I had to add these lines to tools/build/v1/gcc-tools.jam: GCC_STDLIB64_DIRECTORY ?= $(GCC_ROOT_DIRECTORY)$(SLASH)lib64 ; flags gcc STDLIBPATH $(.ARCH)/<instruction-set>default : $(GCC_STDLIB_DIRECTORY) ; flags gcc STDLIBPATH $(.ARCH)/<instruction-set>pentium4 : $(GCC_STDLIB_DIRECTORY) ; flags gcc STDLIBPATH $(.ARCH)/<instruction-set>opteron : $(GCC_STDLIB64_DIRECTORY) ; flags gcc STDLIBPATH : $(GCC_STDLIB_DIRECTORY) ; I also commented out this line in the same file: #flags gcc STDLIBPATH : $(GCC_STDLIB_DIRECTORY) ; And I add this option to the bjam command line: -sBUILD="<instruction-set>opteron" I hope that someone has fixed this and other similar opteron-related problems for 1.34.0. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Neal Becker wrote:
ICU_LDFLAGS= -L$(ICU_PATH)/lib
This is wrong. On x86_64, the path is .../lib64.
Can we maybe find a better way to do this?
Hmmm, build with bjam? The makefiles are provided as a "for instance" and bjam is now the "official" way to build. But in any case if ICU is installed maybe specifying the lib path is superfluous anyway? Can we rely on everything being in the usual search paths on Unix systems? Thanks, John.
John Maddock wrote:
Neal Becker wrote:
ICU_LDFLAGS= -L$(ICU_PATH)/lib
This is wrong. On x86_64, the path is .../lib64.
Can we maybe find a better way to do this?
Hmmm, build with bjam?
The makefiles are provided as a "for instance" and bjam is now the "official" way to build.
But in any case if ICU is installed maybe specifying the lib path is superfluous anyway? Can we rely on everything being in the usual search paths on Unix systems?
That was with bjam.
Neal Becker wrote:
But in any case if ICU is installed maybe specifying the lib path is superfluous anyway? Can we rely on everything being in the usual search paths on Unix systems?
That was with bjam.
Oh :-( Digging deaper, it looks like the bbv1 and bbv2 got out of synch at some point, I'll have to look at this again. John.
John Maddock wrote:
Neal Becker wrote:
But in any case if ICU is installed maybe specifying the lib path is superfluous anyway? Can we rely on everything being in the usual search paths on Unix systems?
That was with bjam.
Oh :-(
Digging deaper, it looks like the bbv1 and bbv2 got out of synch at some point, I'll have to look at this again.
Let me clarify this. Sorry if I mispoke. I ran bjam and observed: gcc.link.dll bin.v2/libs/regex/build/gcc-4.1.1/release/libboost_regex.so /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc This tells me something is doing -L/usr/lib, and it shouldn't be doing that. So, I searched around (blindly) to see where it was coming from. I think I mis-identified gcc-shared.mak as the culprit. Point is, there IS a problem somewhere.
Neal Becker wrote:
I ran bjam and observed: gcc.link.dll bin.v2/libs/regex/build/gcc-4.1.1/release/libboost_regex.so /usr/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc
This tells me something is doing -L/usr/lib, and it shouldn't be doing that.
So, I searched around (blindly) to see where it was coming from. I think I mis-identified gcc-shared.mak as the culprit. Point is, there IS a problem somewhere.
Well not from the makefile, that's for sure! I'll try and reproduce this: probably tomorrow now. John.
Hi ! On Friday 05 January 2007 19:45, John Maddock wrote:
Neal Becker wrote:
I ran bjam and observed: gcc.link.dll This tells me something is doing -L/usr/lib, and it shouldn't be doing that.
The matter is more complex :-(( The problem is distribution-specific. It shows only when using a combined 64/32-bit distribution like SuSE-10.x, which I use at work. Pure 64bit distributions like debian-AMD64 don't have this problem. I use the attached patch to fool the regex build that is _has_ found the libraries and then use the following in my user-confing.jam on SuSE-10-x: # GCC configuration using gcc : 4.1 : <wrapper-script>.sh : # options <cxxflags>-m64 <linkflags>-L/usr/X11R6/lib64 <linkflags>-L/usr/lib64 <linkflags>-L/opt/gnome/lib64 # for glib-2.0 on SuSE This does the trick for me... On debian-AMD64, everything works out-of-the-box...
So, I searched around (blindly) to see where it was coming from. I think I mis-identified gcc-shared.mak as the culprit. Point is, there IS a problem somewhere.
Well, yes. The current build system does not identify the correct platform, that is, we are missing <addressmodel> or <arichtecture> options for at least gcc on linux and msvc-8.0 ... But I'm not sure we can solve this before 1.34.0... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold@ivembh.de ! www.ivembh.de
Neal Becker wrote:
So, I searched around (blindly) to see where it was coming from. I think I mis-identified gcc-shared.mak as the culprit. Point is, there IS a problem somewhere.
Neal: could you please drop the attached Jamfile into libs/regex/build and give it a go. It should do the right thing if you either: bjam -sICU_PATH=/usr/local or: bjam -sHAVE_UCU=1 the latter option just searches your std paths, and is the one to use if ICU is actually installed rather than just sitting on you HD somewhere. But they both should now more or less work! Thanks, John.
participants (4)
-
John Maddock -
Juergen Hunold -
Neal Becker -
Richard Hadsell