I have Fedora (pre-FC4). There are packages for icu: libicu, libicu-devel, libicu-doc which I installed. I can't seem to convince bjam to use them. What do I need to do? Headers are in /usr/include/unicode (e.g., /usr/include/utypes.h). Libs are rpm -ql libicu /usr/lib64/libicudata.so.32 /usr/lib64/libicudata.so.32.0 /usr/lib64/libicui18n.so.32 /usr/lib64/libicui18n.so.32.0 /usr/lib64/libicuio.so.32 /usr/lib64/libicuio.so.32.0 /usr/lib64/libicule.so.32 /usr/lib64/libicule.so.32.0 /usr/lib64/libiculx.so.32 /usr/lib64/libiculx.so.32.0 /usr/lib64/libicutu.so.32 /usr/lib64/libicutu.so.32.0 /usr/lib64/libicuuc.so.32 /usr/lib64/libicuuc.so.32.0
I have Fedora (pre-FC4). There are packages for icu: libicu, libicu-devel, libicu-doc which I installed.
I can't seem to convince bjam to use them. What do I need to do?
Headers are in /usr/include/unicode (e.g., /usr/include/utypes.h). Libs are rpm -ql libicu /usr/lib64/libicudata.so.32
The Jamfiles getting confused because the libs are under a different path to the headers, try: export ICU_PATH=/usr export ICU_LINK="-licuuc -licui18n" bjam stage # or whatever Hopefully that should work, John.
John Maddock wrote:
I have Fedora (pre-FC4). There are packages for icu: libicu, libicu-devel, libicu-doc which I installed.
I can't seem to convince bjam to use them. What do I need to do?
Headers are in /usr/include/unicode (e.g., /usr/include/utypes.h). Libs are rpm -ql libicu /usr/lib64/libicudata.so.32
The Jamfiles getting confused because the libs are under a different path to the headers, try:
export ICU_PATH=/usr export ICU_LINK="-licuuc -licui18n" bjam stage # or whatever
Hopefully that should work,
Works, but could be better: ICU_PATH=/usr ICU_LINK="-licuuc -licui18n" PYTHON_ROOT=/usr PYTHON_VERSION=2.4 bjam -sTOOLS=gcc stage Building Boost.Regex with Unicode/ICU support enabled Using ICU in /usr/include ...found 7586 targets... ...updating 130 targets... gcc-C++-action bin/boost/libs/regex/build/libboost_regex.so/gcc/debug/shared-linkable-true/regex_raw_buffer.o gcc-Link-action bin/boost/libs/regex/build/libboost_regex.so/gcc/debug/shared-linkable-true/libboost_regex-gcc-d-1_33.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 [...] Seems to work, but you see the warnings. This is on Fedora x86_64. Apparantly, someone added -L/usr/lib, which would cause those annoying warnings.
/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 [...]
Seems to work, but you see the warnings. This is on Fedora x86_64. Apparantly, someone added -L/usr/lib, which would cause those annoying warnings.
That would be me! I'm going to have to think about this one, having two sets of system libraries is going to be a pain to configure around. John.
John Maddock wrote:
/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 [...]
Seems to work, but you see the warnings. This is on Fedora x86_64. Apparantly, someone added -L/usr/lib, which would cause those annoying warnings.
That would be me! I'm going to have to think about this one, having two sets of system libraries is going to be a pain to configure around.
I'll be happy if you just let me specify manually, I'm quite used to configure --libdir=/usr/lib64
That would be me! I'm going to have to think about this one, having two sets of system libraries is going to be a pain to configure around.
I'll be happy if you just let me specify manually, I'm quite used to configure --libdir=/usr/lib64
Yep, it's just getting it all done in the bjam language that's the tricky bit, but you're right of course. John.
* John Maddock (john@johnmaddock.co.uk) [20050608 19:01]:
Apparantly, someone added -L/usr/lib, which would cause those annoying warnings.
That would be me!
Pray tell me, why would you add the path to the standard library directory gcc/ld will search by default? Simply leave it away and the tools will search in the right place by default.
having two sets of system libraries is going to be a pain to configure around.
Why "configure around"? Yes, these systems need to be catered for, like putting the libraries to be built in /usr/lib64. But what do you need to work around? Philipp -- Philipp Thomas <pth@suse.de> Research & Development SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuremberg, Germany
Pray tell me, why would you add the path to the standard library directory gcc/ld will search by default? Simply leave it away and the tools will search in the right place by default.
bjam doesn't know that it's been told to look in a std path, it's just been told to "look here", wherever "here" is. Whatever I working on a fix to improve this. John.
John Maddock wrote:
Pray tell me, why would you add the path to the standard library directory gcc/ld will search by default? Simply leave it away and the tools will search in the right place by default.
bjam doesn't know that it's been told to look in a std path, it's just been told to "look here", wherever "here" is. Whatever I working on a fix to improve this.
It is generally quite dangerous to explicitely add standard paths (at least for include paths). Gcc goes to great length to provide wrapper headers that fix certain bugs / incompatibilities in system headers, and explicitely adding '-I/usr/include' would circumvent this mechanism. I'm not sure whether there is any similar issue with library paths, though. FWIW, Stefan
Stefan Seefeld wrote:
John Maddock wrote:
Pray tell me, why would you add the path to the standard library directory gcc/ld will search by default? Simply leave it away and the tools will search in the right place by default.
bjam doesn't know that it's been told to look in a std path, it's just been told to "look here", wherever "here" is. Whatever I working on a fix to improve this.
It is generally quite dangerous to explicitely add standard paths (at least for include paths). Gcc goes to great length to provide wrapper headers that fix certain bugs / incompatibilities in system headers, and explicitely adding '-I/usr/include' would circumvent this mechanism. I'm not sure whether there is any similar issue with library paths, though.
Maybe this gcc option could be useful? `-print-file-name=LIBRARY' Print the full absolute name of the library file LIBRARY that would be used when linking--and don't do anything else. With this option, GCC does not compile or link anything; it just prints the file name. I think what's really needed is a pkg-config for gcc
Maybe this gcc option could be useful?
`-print-file-name=LIBRARY' Print the full absolute name of the library file LIBRARY that would be used when linking--and don't do anything else. With this option, GCC does not compile or link anything; it just prints the file name.
No sorry: as the build system works at present, any configuration has to be done within the jam language, using rules that don't execute any commands! If I could execute commands to do the configuration this would be easy :-) But whatever, I've committed a fix that I believe solves the main issues: certainly std paths shouldn't be added to the include or library search paths any more (by std paths I mean /usr/include and /usr/local/include), it's still technically possible for this to do the wrong thing (if a path other than /usr or /usr/local is a std install prefix), but IMO it's very unlikely now. I've also changed the behavior when the ICU lib files aren't found under $(ICU_PATH)/lib: then it prints a warning, but still adds the "usual" library names to the linker command line in the hope that they'll be found in a std path somewhere. Note however that ICU doesn't really have a consistent naming convention for it's libs: they change quite radically depending upon the platform, so this probably only works on Linux, and maybe one or two other Unixes. Finally, note that I've just corrected a couple of minor bugs in the ICU support code, so you may want to do a cvs update for these alone (one for the regex-iterators, plus one very obscure bug for "ignorable" collating elements). HTH, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Maybe this gcc option could be useful?
`-print-file-name=LIBRARY' Print the full absolute name of the library file LIBRARY that would be used when linking--and don't do anything else. With this option, GCC does not compile or link anything; it just prints the file name.
No sorry: as the build system works at present, any configuration has to be done within the jam language, using rules that don't execute any commands! If I could execute commands to do the configuration this would be easy :-)
Someone just posted a patch that would enable that functionality, if it works.
But whatever, I've committed a fix that I believe solves the main issues: certainly std paths shouldn't be added to the include or library search paths any more (by std paths I mean /usr/include and /usr/local/include), it's still technically possible for this to do the wrong thing (if a path other than /usr or /usr/local is a std install prefix), but IMO it's very unlikely now.
Now wait a minute. If you download and build GCC from source, you pretty much have to install it with a nonstandard prefix or your system will get messed up, and I do that all the time. You don't need to do anything about #include paths, but the LD_LIBRARY_PATH and, possibly -L, do need to be set differently. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Now wait a minute. If you download and build GCC from source, you pretty much have to install it with a nonstandard prefix or your system will get messed up, and I do that all the time. You don't need to do anything about #include paths, but the LD_LIBRARY_PATH and, possibly -L, do need to be set differently.
Right, but that's only an issue with the new build script if gcc is installed in a user-defined location, and ICU is in the same location. In this case the build script will needlessly add the "std" include and lib paths to the command line, which as previously noted may mess up wrapper headers and the like. I don't know how to fix that easily at present, what does Boost.Python do, it has a similar problem - ah I see, python headers/binaries never end up in the std locations anyway is that right? John.
"John Maddock" <john@johnmaddock.co.uk> writes:
Now wait a minute. If you download and build GCC from source, you pretty much have to install it with a nonstandard prefix or your system will get messed up, and I do that all the time. You don't need to do anything about #include paths, but the LD_LIBRARY_PATH and, possibly -L, do need to be set differently.
Right, but that's only an issue with the new build script if gcc is installed in a user-defined location, and ICU is in the same location. In this case the build script will needlessly add the "std" include and lib paths to the command line, which as previously noted may mess up wrapper headers and the like. I don't know how to fix that easily at present, what does Boost.Python do, it has a similar problem - ah I see, python headers/binaries never end up in the std locations anyway is that right?
Sorry, I'm probably being dense, but I don't know what "the std locations" means. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Tue, Jun 14, 2005 at 11:06:19AM +0100, John Maddock wrote:
Now wait a minute. If you download and build GCC from source, you pretty much have to install it with a nonstandard prefix or your system will get messed up, and I do that all the time. You don't need to do anything about #include paths, but the LD_LIBRARY_PATH and, possibly -L, do need to be set differently.
Right, but that's only an issue with the new build script if gcc is installed in a user-defined location, and ICU is in the same location. In
e.g. a box where you don't have root access, so have installed gcc and ICU with --prefix=$HOME ? That doesn't seem like an unreasonable or uncommon setup to me. Apologies if I've misunderstood. jon
this case the build script will needlessly add the "std" include and lib paths to the command line, which as previously noted may mess up wrapper headers and the like. I don't know how to fix that easily at present, what does Boost.Python do, it has a similar problem - ah I see, python headers/binaries never end up in the std locations anyway is that right?
Right, but that's only an issue with the new build script if gcc is installed in a user-defined location, and ICU is in the same location. In
e.g. a box where you don't have root access, so have installed gcc and ICU with --prefix=$HOME ?
That doesn't seem like an unreasonable or uncommon setup to me.
Apologies if I've misunderstood.
No need: you understand correctly. John.
* John Maddock (john@johnmaddock.co.uk) [20050613 12:16]:
any configuration has to be done within the jam language, using rules that don't execute any commands!
You mean you can't even adapt to changing gcc versions in the bjam configuration? I *knew* why I dislike build systems that can't adapt themselves to changing system configurations (in the way autoconf does its work). Seems like an autojam is desperately needed (and no, I'm not volunteering :).
If I could execute commands to do the configuration this would be easy :-)
I've also changed the behavior when the ICU lib files aren't found under $(ICU_PATH)/lib: then it prints a warning, but still adds the "usual" library names to the linker command line in the hope that they'll be found in a std path somewhere.
That's very reasonable, given the constraints you have. Thanks! Philipp -- Philipp Thomas <pth@suse.de> Research & Development SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuremberg, Germany
participants (6)
-
David Abrahams -
John Maddock -
Jonathan Wakely -
Neal Becker -
Philipp Thomas -
Stefan Seefeld