When I tried to upgrade boost-1.32, compile script could not be found and no error code was returned, so there was nothing to install which resulted in silent remove of old boost installation. here is the log: athlon wojtek # emerge --oneshot dev-libs/boost Calculating dependencies ...done! >>> emerge (1 of 1) dev-libs/boost-1.32.0 to / >>> md5 src_uri ;-) boost_1_32_0.tar.bz2 >>> Unpacking source... >>> Unpacking boost_1_32_0.tar.bz2 to /var/tmp/portage/boost-1.32.0/work >>> Source unpacked. ### ### Using 'gcc' toolset. ### rm -rf bootstrap.gcc mkdir bootstrap.gcc gcc -o bootstrap.gcc/jam0 command.c compile.c execnt.c execunix.c execvms.c expand.c filent.c fileos2.c fileunix.c filevms.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c pathunix.c pathvms.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c ./bootstrap.gcc/jam0 -f build.jam --toolset=gcc --toolset-root= clean ...found 1 target... ...updating 1 target... ...updated 1 target... ./bootstrap.gcc/jam0 -f build.jam --toolset=gcc --toolset-root= ...found 82 targets... ...updating 6 targets... .mkdir. bin.linuxx86 .cc. bin.linuxx86/yyacc .cc. bin.linuxx86/mkjambase .mkjambase. jambase.c .cc. bin.linuxx86/jam .link. bin.linuxx86/bjam ...updated 6 targets... /usr/portage/dev-libs/boost/boost-1.32.0.ebuild: line 31: ./tools/build/jam_src/bin.linux/bjam: Nie ma takiego pliku ani katalogu >>> Test phase [not enabled]: dev-libs/boost-1.32.0 >>> Install boost-1.32.0 into /var/tmp/portage/boost-1.32.0/image/ category dev-libs [...] Reproducible: Always Steps to Reproduce: emerge dev-libs/boost-1.32.0
The ebuild contains a path to bjam (twice): ./tools/build/jam_src/bin.linux/bjam try changing it to (at least on x86): ./tools/build/jam_src/bin.linuxx86/bjam
added ${arch} to bjam path
fails way down the line, working on it
it shouldn't || die on stage testing
please test all should be well now
Declaring arch local in src_compile() makes it invisible to src_install(), so the install still can't find bjam and fails. Comment out the "local arch" line and it works just fine. Another thing, wouldn't it be easier to use python_version() in the python eclass instead of all the sed stuff in this ebuild?
nullzone boost # ls /usr/include/boost/ Display all 139 possibilities? (y or n) algorithm/ dynamic_bitset/ last_value.hpp program_options/ spirit/ aligned_storage.hpp dynamic_bitset_fwd.hpp lexical_cast.hpp program_options.hpp spirit.hpp any.hpp dynamic_bitset.hpp limits.hpp progress.hpp state_saver.hpp archive/ enable_shared_from_this.hpp logic/ property_map.hpp static_assert.hpp array.hpp filesystem/ math/ property_map_iterator.hpp static_warning.hpp assert.hpp format/ math_fwd.hpp python/ strong_typedef.hpp assign/ format.hpp mem_fn.hpp python.hpp test/ assign.hpp function/ mpl/ random/ thread/ bind/ functional.hpp multi_array/ random.hpp thread.hpp bind.hpp function_equal.hpp multi_array.hpp range/ throw_exception.hpp blank_fwd.hpp function.hpp multi_index/ range.hpp timer.hpp blank.hpp function_output_iterator.hpp multi_index_container_fwd.hpp rational.hpp token_functions.hpp call_traits.hpp generator_iterator.hpp multi_index_container.hpp ref.hpp token_iterator.hpp cast.hpp get_pointer.hpp next_prior.hpp regex/ tokenizer.hpp checked_delete.hpp graph/ noncopyable.hpp regex_fwd.hpp tuple/ compatibility/ implicit_cast.hpp nondet_random.hpp regex.h type.hpp compressed_pair.hpp indirect_reference.hpp none.hpp regex.hpp type_traits/ concept_archetype.hpp integer/ non_type.hpp scoped_array.hpp type_traits.hpp concept_check.hpp integer_fwd.hpp numeric/ scoped_ptr.hpp utf8_codecvt_facet.hpp config/ integer.hpp operators.hpp serialization/ utility/ config.hpp integer_traits.hpp optional/ shared_array.hpp utility.hpp crc.hpp intrusive_ptr.hpp optional.hpp shared_container_iterator.hpp variant/ cregex.hpp io/ pending/ shared_ptr.hpp variant.hpp cstdint.hpp io_fwd.hpp pfto.hpp signal.hpp vector_property_map.hpp cstdlib.hpp iterator/ pointee.hpp signals/ version.hpp current_function.hpp iterator_adaptors.hpp pool/ signals.hpp visit_each.hpp date_time/ iterator.hpp preprocessor/ smart_cast.hpp weak_ptr.hpp detail/ lambda/ preprocessor.hpp smart_ptr.hpp nullzone boost # ls /usr/include/boost/ better?
Now it seems to compile, but when I tried to compile monotone (http://bugs.gentoo.org/show_bug.cgi?id=39383) configure stops with that log in config.log: configure:7968: checking libboost_unit_test_framework library configure:7985: i686-pc-linux-gnu-g++ -o conftest -fno-stack-protector-all -fno-stack-protector -O2 -fno-strict-aliasing conftest.cc -lboost_unit_test_framework >&5 conftest.cc:33:42: boost/test/unit_test_suite.hpp: No such file or directory conftest.cc:34:37: boost/test/test_tools.hpp: No such file or directory conftest.cc:35: error: `boost' has not been declared conftest.cc:35: error: expected nested-name-specifier before "test_suite" conftest.cc:35: error: `test_suite' has not been declared conftest.cc:36: error: expected constructor, destructor, or type conversion before '*' token conftest.cc:36: error: expected `,' or `;' before '*' token configure:7991: $? = 1 configure: failed program was: | /* confdefs.h. */ I'm not sure if that is OK, is version 1.31 incompatibile with 1.32?
Now I see, I checked /var/db/pkg/dev-libs/boost-1.32.0/CONTENTS file, and I assumed that there is only /usr/share/doc/boost/* instlled with documentaion. So the ebuild is still invalid.
yes it was, now if you know boost really good (i used it but only the source header stuff, never used bjam, (pointing VS.net at the dir and voila all works (i used)) ok this one builds most all why i asked if you know boost well? it builds all but 4 targets from looks of it at least if you sync 35 minutes after this message there will be a 1.32.0 ebuild that installs boost, not only the docs if it passes your test case i dont know, id like to hear about it for sure reopening bug so others dont create duplicates
It still instals only /usr/share directory for me, I noticed that after compilation, which I think works well, there's another problem with finding bjam during install stage and I think that's the reason.
nothing is installed for you in /usr/include/boost/ ? can you --sync and try again?
I did it about 4 times today (last time about 30 min. ago), but there's still the same problem. I have no /usr/include/boost directory after instalation of boost-1.32, and documentation is only thing that exists on my disk right now form this ebuild.
I tried it today also, Sun, 12 Dec 2004 13:51:54 -0500, the newer version actually compiles the package but does not install the compiled bits. x86 gcc 3.4.3
The full stop got lost off the front of the install line. i.e.: src_install () { /tools/build/jam_src/bin.linux${arch}/bjam ${MAKEOPTS} \ should be: src_install () { ./tools/build/jam_src/bin.linux${arch}/bjam ${MAKEOPTS} \
Created attachment 45838 [details] variable to prevent heinous boost-jam lossage better to refer to this binary by its full name only once.
Does not install boost.build
${BOOSTJAM} is being added and tested right now id like to know how i ended up with the dir+files, possibly it wasnt cleaned up, then again considering i didnt have any prvious version of boost i cant explain having the files i apologize for the extra time it takes to get this right and thank you all for your input
i guess i never mentioned i added the fixed and seemingly working ebuild to portage --sync please :)
no more problem comments, files are installed, looks done
There's still one problem, but I don't know if it is boost related or this build related. Every installed library has 'gcc-*-1_32' suffix which prevents properly linking against them. Also include directory looks like it could be more versions of boost instlalled together. Maybe it should be fixed during install stage?
Created attachment 46303 [details, diff] more convenient way of files hierarchy
I looked at the way of instalation boost, and figured out that there's a lot of hardlinks and symlinks between libraries that are simply redundant. I made more common way to organize this files. First I remove all redundant files, and then I make more conventional symlinks (without 1_32 version suffix, because of eventually backward compatibility) to proper libraries. Last thing is to make symlinks to libraries that we will link against by default (without worrying about suffixes). I choosed multitherated dynamic versions like earlier ebuild did. I send patch for that modification. What do you think about that?
I forgot, I checked it if there are really redundant files: for i in /usr/lib/libboost*1_32.{a,so}; do diff -s $i `echo $i | sed 's/\(.*\)-1_32\(.*\)/\1\2/'`; done
You might find that using --layout=system will sort out the extraneous symlinking and various 1_32 in file names.
That's right, I did't read bjam/boost options. I think this flag should be used by default.
