Recently, the code for multilib a lot has been added. Thanks aballier. I think need for 32-bit c++ library for a complete initial multilib support. I'll attach sample patches. # clang++ -stdlib=libc++ -m32 -v -o hello hello.cc clang version 3.3 (tags/RELEASE_33/final) Target: i386-gentoo-freebsd9.1 Thread model: posix "/usr/bin/clang" -cc1 -triple i386-gentoo-freebsd9.1 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name hello.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486 -target-linker-version 2.22 -v -resource-dir /usr/bin/../lib/clang/3.3 -internal-isystem /usr/include/c++/v1 -fdeprecated-macro -fdebug-compilation-dir /root -ferror-limit 19 -fmessage-length 124 -mstackrealign -fobjc-runtime=gnustep -fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops -o /tmp/hello-5YUdXs.o -x c++ hello.cc clang -cc1 version 3.3 based upon LLVM 3.3 default target x86_64-gentoo-freebsd9.1 ignoring duplicate directory "/usr/include/c++/4.2" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/v1 /usr/include/c++/4.2 /usr/include/c++/4.2/backward /usr/bin/../lib/clang/3.3/include /usr/include End of search list. "/usr/bin/x86_64-gentoo-freebsd9.1-ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 --hash-style=both --enable-new-dtags -m elf_i386_fbsd -o hello /usr/lib32/crt1.o /usr/lib32/crti.o /usr/lib32/crtbegin.o -L/usr/lib32 /tmp/hello-5YUdXs.o -lc++ -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib32/crtend.o /usr/lib32/crtn.o /usr/bin/x86_64-gentoo-freebsd9.1-ld: skipping incompatible /usr/lib/libc++.so when searching for -lc++ /usr/bin/x86_64-gentoo-freebsd9.1-ld: skipping incompatible /usr/lib/libc++.a when searching for -lc++ /usr/bin/x86_64-gentoo-freebsd9.1-ld: cannot find -lc++ clang: error: linker command failed with exit code 1 (use -v to see invocation)
Created attachment 352308 [details, diff] patch for multilib-build.eclass add abi detect code for Gentoo/FreeBSD.
Created attachment 352314 [details, diff] patch for amd64/9.1/clang profile
Created attachment 352316 [details, diff] patch for libcxxrt-0.0_p20130531.ebuild passed the test on Gentoo/FreeBSD amd64 (patched clang profile) * x86_fbsd: running multilib-minimal_abi_src_test gmake -j5 check clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -O2 -pipe -c -o test.o test.cc clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -O2 -pipe -c -o test_exception.o test_exception.cc clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -O2 -pipe -c -o test_guard.o test_guard.cc clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -O2 -pipe -c -o test_typeinfo.o test_typeinfo.cc clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -nodefaultlibs -O2 -pipe -Wl,-z,defs -Wl,-z,defs -o cxxrttest test.o test_exception.o test_guard.o test_typeinfo.o -L/var/tmp/portage/sys-libs/libcxxrt-0.0_p20130531/work/libcxxrt-0.0_p20130531-x86_fbsd/src -lcxxrt -lc clang: warning: argument unused during compilation: '-stdlib=libc++' ./cxxrttest 35 tests, 35 passed, 0 failed * amd64_fbsd: running multilib-minimal_abi_src_test gmake -j5 check clang++ -stdlib=libc++ -O2 -pipe -c -o test.o test.cc clang++ -stdlib=libc++ -O2 -pipe -c -o test_exception.o test_exception.cc clang++ -stdlib=libc++ -O2 -pipe -c -o test_guard.o test_guard.cc clang++ -stdlib=libc++ -O2 -pipe -c -o test_typeinfo.o test_typeinfo.cc clang++ -stdlib=libc++ -nodefaultlibs -O2 -pipe -Wl,-z,defs -Wl,-z,defs -o cxxrttest test.o test_exception.o test_guard.o test_typeinfo.o -L/var/tmp/portage/sys-libs/libcxxrt-0.0_p20130531/work/libcxxrt-0.0_p20130531-amd64_fbsd/src -lcxxrt -lc clang: warning: argument unused during compilation: '-stdlib=libc++' ./cxxrttest 35 tests, 35 passed, 0 failed
Created attachment 352318 [details, diff] sample patch for libcxx-0.0_p20130531-r1.ebuild Better patch and comments very welcome ;-)
How to test wget http://dev.gentoo.org/~aballier/fbsd9.1/amd64/clang/stage3-amd64-clangfbsd-9.1.tar.bz2 tar xjpf stage3-amd64-clangfbsd-9.1.tar.bz2 mount /dev, prepare portage tree... etc. chrooting! cd /usr/portage wget -O profile.patch "https://bugs.gentoo.org/attachment.cgi?id=352314" patch -p0 < profile.patch cd /usr/portage/eclass wget -O multilib-build.eclass.patch "https://bugs.gentoo.org/attachment.cgi?id=352308" patch -p0 < multilib-build.eclass.patch cd /usr/portage/sys-libs/libcxxrt wget -O libcxxrt.patch "https://bugs.gentoo.org/attachment.cgi?id=352316" patch -p0 < libcxxrt.patch ebuild libcxxrt-0.0_p20130531.ebuild digest cd /usr/portage/sys-libs/libcxx wget -O libcxx.patch "https://bugs.gentoo.org/attachment.cgi?id=352318" patch -p0 < libcxx.patch ebuild libcxx-0.0_p20130531-r1.ebuild digest note) When for the first time, libcxx and libcxxrt with 32-bit library is required. In this example, use a binary package that I created. mkdir -p /usr/portage/packages/sys-libs cd /usr/portage/packages/sys-libs wget http://dev.gentoo.gr.jp/~nigoro/amd64-fbsd/files/libcxx-0.0_p20130531-r1.tbz2 wget http://dev.gentoo.gr.jp/~nigoro/amd64-fbsd/files/libcxxrt-0.0_p20130531.tbz2 emerge -K libcxx libcxxrt OK. will be able to create 32-bit library of its own. try, emerge libcxx libcxxrt
Created attachment 352320 [details, diff] sample patch for libcxx-0.0_p20130531-r1.ebuild Fix my mistake. LD_LIBRARY_PATH --> LD_32_LIBRARY_PATH
Oh, I see you're reusing the same flags as for Linux. Wasn't there any issues with that?
Created attachment 352386 [details] list of tested packages and others. (In reply to Michał Górny from comment #7) > Oh, I see you're reusing the same flags as for Linux. Wasn't there any > issues with that? Results that I tested, seemed function of multilib-build to work. I'll attach a list of tested packages. I noticed that abi_x86_32? ( category/package ) is included in some packages. I think need some changes in order to not break the dependencies. Only Linux) amd64? ( abi_x86_32? ( category/package ) ) Only FreeBSD) amd64-fbsd? ( abi_x86_32? ( category/package ) ) Both Linux/FreeBSD) abi_x86_32? ( category/package )
(In reply to Yuta SATOH from comment #6) > Created attachment 352320 [details, diff] [details, diff] > sample patch for libcxx-0.0_p20130531-r1.ebuild > > Fix my mistake. > LD_LIBRARY_PATH --> LD_32_LIBRARY_PATH Behavior of LD_LIBRARY_PATH is different in Linux and FreeBSD. Linux) $ file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped $ ldd hello linux-gate.so.1 (0xffffe000) libc.so.6 => /lib32/libc.so.6 (0xf754e000) /lib/ld-linux.so.2 (0xf76e9000) $ LD_LIBRARY_PATH="/lib32" ldd hello linux-gate.so.1 (0xffffe000) libc.so.6 => /lib32/libc.so.6 (0xf755a000) /lib/ld-linux.so.2 (0xf76e4000) FreeBSD) $ file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked (uses shared libs), for FreeBSD 9.1, not stripped $ ldd hello hello: libc.so.7 => /usr/lib32/libc.so.7 (0x2806a000) $ LD_LIBRARY_PATH="/usr/lib32" ldd hello /usr/lib32/libc.so.7: unsupported file layout Probably, I think that can not mix 32-bit/64-bit in the LD_LIBRARY_PATH on FreeBSD. need to use LD_32_LIBRARY_PATH for 32-bit libraries. $ LD_32_LIBRARY_PATH="/usr/lib32" ldd hello hello: libc.so.7 => /usr/lib32/libc.so.7 (0x2806a000)
(In reply to Michał Górny from comment #7) > Oh, I see you're reusing the same flags as for Linux. Wasn't there any > issues with that? the issue is what is fixed by the second hunk i think; and also me not believing it could be that simple :)
(In reply to Yuta SATOH from comment #5) > note) When for the first time, libcxx and libcxxrt with 32-bit library is > required. > In this example, use a binary package that I created. this is nasty, could you please try if my last commit helps avoiding using a binpkg ? + 01 Jul 2013; Alexis Ballier <aballier@gentoo.org> + libcxx-0.0_p20130531-r1.ebuild, libcxx-9999.ebuild: + use clang -nostdlib / clang++ -nostdlib for compiling to try to avoid chicken + and egg problems when bootstrapping. +
(In reply to Yuta SATOH from comment #2) > Created attachment 352314 [details, diff] [details, diff] > patch for amd64/9.1/clang profile I'd rather do it in arch/amd64-fbsd. multilib gcc is broken on fbsd though, maybe something like this: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/freebsd.eclass?r1=1.26&r2=1.27 added to multilib cflags in the profile could fix it
(In reply to Yuta SATOH from comment #9) > (In reply to Yuta SATOH from comment #6) > > Created attachment 352320 [details, diff] [details, diff] [details, diff] > > sample patch for libcxx-0.0_p20130531-r1.ebuild > > > > Fix my mistake. > > LD_LIBRARY_PATH --> LD_32_LIBRARY_PATH > > Behavior of LD_LIBRARY_PATH is different in Linux and FreeBSD. what if you do LD_LIBRARY_PATH="/usr/lib32:${LD_LIBRARY_PATH}" ?
(In reply to Alexis Ballier from comment #11) > (In reply to Yuta SATOH from comment #5) > > note) When for the first time, libcxx and libcxxrt with 32-bit library is > > required. > > In this example, use a binary package that I created. > > this is nasty, could you please try if my last commit helps avoiding using a > binpkg ? > > + 01 Jul 2013; Alexis Ballier <aballier@gentoo.org> > + libcxx-0.0_p20130531-r1.ebuild, libcxx-9999.ebuild: > + use clang -nostdlib / clang++ -nostdlib for compiling to try to avoid > chicken > + and egg problems when bootstrapping. > + I tried new libcxx. multilib compile was successful without my binary package. However, I have found a new problem. Please see bug 475500.
Created attachment 352508 [details, diff] sample patch for freebsd-lib-9.1-r9.ebuild libcxx checks if librt exists. However, it does not exist in /usr/lib32. I'll attach a patch, add librt to /usr/lib32. FYI, libcxx configure log) -- Looking for clock_gettime in rt -- Looking for clock_gettime in rt - not found $ ls /usr/lib32/librt* ls: /usr/lib32/librt*: No such file or directory $ ldd /usr/lib/libc++.so.1.0 (64bit library) /usr/lib/libc++.so.1.0: libcxxrt.so.1 => /usr/lib/libcxxrt.so.1 (0x8012ba000) libthr.so.3 => /lib/libthr.so.3 (0x8014d4000) libc.so.7 => /lib/libc.so.7 (0x80081d000) librt.so.1 => /usr/lib/librt.so.1 (0x8016f7000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x8018fd000) $ ldd /usr/lib32/libc++.so.1.0 /usr/lib32/libc++.so.1.0: libcxxrt.so.1 => /usr/lib32/libcxxrt.so.1 (0x2824b000) libthr.so.3 => /usr/lib32/libthr.so.3 (0x28263000) libc.so.7 => /usr/lib32/libc.so.7 (0x2806d000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0x28283000)
Created attachment 352514 [details, diff] dirty sample patch for libcxxrt-0.0_p20130531-r1.ebuild (target rev 1.4) very bad patch. but, it's possible to make 32/64bit library to work correctly without binpkg. Until is closed bug 475500, I will do the test of multilib using this patch.
Created attachment 352516 [details, diff] files/libcxx-0.0_p20130531-minimal-build.patch i'll attach patch that attachment 352514 [details, diff] needs
(In reply to Alexis Ballier from comment #13) > (In reply to Yuta SATOH from comment #9) > > (In reply to Yuta SATOH from comment #6) > > > Created attachment 352320 [details, diff] [details, diff] [details, diff] [details, diff] > > > sample patch for libcxx-0.0_p20130531-r1.ebuild > > > > > > Fix my mistake. > > > LD_LIBRARY_PATH --> LD_32_LIBRARY_PATH > > > > Behavior of LD_LIBRARY_PATH is different in Linux and FreeBSD. > > what if you do LD_LIBRARY_PATH="/usr/lib32:${LD_LIBRARY_PATH}" ? I have noticed this problem first, test phase of libcxxrt. * x86_fbsd: running multilib-minimal_abi_src_test gmake -j1 check clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -stdlib=libc++ -O2 -pipe -mtune=generic -c -o test.o test.cc /var/tmp/portage/sys-libs/libcxxrt-0.0_p20130531/work/libcxxrt-0.0_p20130531-x86_fbsd/src/libcxxrt.so.1: unsupported file layout gmake: *** [test.o] Error 1 * ERROR: sys-libs/libcxxrt-0.0_p20130531 failed (test phase): $ LD_LIBRARY_PATH="/usr/lib32:${LD_LIBRARY_PATH}" ldd ~/hello /usr/lib32/libc.so.7: unsupported file layout $ LD_LIBRARY_PATH="/usr/lib32:/usr/lib" ldd ~/hello /usr/lib32/libc.so.7: unsupported file layout $ LD_LIBRARY_PATH="/usr/lib" LD_32_LIBRARY_PATH="/usr/lib32" ldd ~/hello /home/nigoro/hello: libc.so.7 => /usr/lib32/libc.so.7 (0x2806a000) No problem if you are just running. $ LD_LIBRARY_PATH="/usr/lib32:/usr/lib" ~/hello Hello, world!
(In reply to Yuta SATOH from comment #16) > Created attachment 352514 [details, diff] [details, diff] + if [[ ${ABI} == x86_fbsd ]] ; then + export LD_32_LIBRARY_PATH="${BUILD_DIR}/lib:${LD_LIBRARY_PATH}" Oops .... It was still the wrong version. need change LD_LIBRARY_PATH --> LD_32_LIBRARY_PATH
(In reply to Yuta SATOH from comment #3) > Created attachment 352316 [details, diff] [details, diff] > patch for libcxxrt-0.0_p20130531.ebuild applied something in those lines in libcxxrt-9999, please test!
please test libcxx-9999: I've rewritten its build system (a binpkg should not be needed) and made it multilib.
Comment on attachment 352508 [details, diff] sample patch for freebsd-lib-9.1-r9.ebuild applied a similar patch in fbsd-lib-9.1-r10. yours would have failed when bootstrapping from no-multilib to multilib.
(In reply to Alexis Ballier from comment #10) > (In reply to Michał Górny from comment #7) > > Oh, I see you're reusing the same flags as for Linux. Wasn't there any > > issues with that? > > the issue is what is fixed by the second hunk i think; and also me not > believing it could be that simple :) so, now what's left is blocked by that multilib-build patch I think. Patch is correct, though, as such it would add duplicated flags to IUSE and multilib_usedep. It is not wrong but IMHO it is ugly. mgorny had suggested moving the definition of _MULTILIB_FLAGS to the profiles but this doesn't solve the duplication problem now that I'm thinking again about it: in any case we _need_ to have all the flags defined so that MULTILIB_USEDEP, which ends up in *DEPEND, is metadata invariant. a possible solution could be to avoid dupication in _multilib_build_set_globals but since this is global scope I'd be very careful about it. @mgorny: opinions on this?
(In reply to Alexis Ballier from comment #23) > (In reply to Alexis Ballier from comment #10) > > (In reply to Michał Górny from comment #7) > > > Oh, I see you're reusing the same flags as for Linux. Wasn't there any > > > issues with that? > > > > the issue is what is fixed by the second hunk i think; and also me not > > believing it could be that simple :) > > so, now what's left is blocked by that multilib-build patch I think. > > Patch is correct, though, as such it would add duplicated flags to IUSE and > multilib_usedep. It is not wrong but IMHO it is ugly. > > mgorny had suggested moving the definition of _MULTILIB_FLAGS to the > profiles but this doesn't solve the duplication problem now that I'm > thinking again about it: in any case we _need_ to have all the flags defined > so that MULTILIB_USEDEP, which ends up in *DEPEND, is metadata invariant. > > a possible solution could be to avoid dupication in > _multilib_build_set_globals but since this is global scope I'd be very > careful about it. > > > @mgorny: opinions on this? I wonder if PMS cares about it. Theoretically speaking, you may sometimes end up with duplicate IUSE values e.g. due to two eclasses defining the same IUSE. If multiple flags are fine for all PMs, I would say leave them. No point in removing duplicates if PM does that run anyway.
Created attachment 352588 [details, diff] pass test phase, sample patch for libcxxrt-9999.ebuild (In reply to Alexis Ballier from comment #20) > (In reply to Yuta SATOH from comment #3) > > Created attachment 352316 [details, diff] [details, diff] [details, diff] > > patch for libcxxrt-0.0_p20130531.ebuild > > applied something in those lines in libcxxrt-9999, please test! (In reply to Alexis Ballier from comment #21) > please test libcxx-9999: I've rewritten its build system (a binpkg should > not be needed) and made it multilib. I was able to create multilib libcxxrt and libcxx without binpkg. However, test phase will fail. sys-libs/libcxxrt-9999) >>> Source compiled. * x86_fbsd: running multilib-minimal_abi_src_test gmake -j1 check clang++ -stdlib=libc++ -m32 -DCOMPAT_32BIT -stdlib=libc++ -O2 -pipe -mtune=generic -c -o test.o test.cc /var/tmp/portage/sys-libs/libcxxrt-9999/work/libcxxrt-9999-x86_fbsd/src/libcxxrt.so.1: unsupported file layout gmake: *** [test.o] Error 1 * ERROR: sys-libs/libcxxrt-9999 failed (test phase): sys-libs/libcxx-9999) >>> Source compiled. * x86_fbsd: running multilib-minimal_abi_src_test /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib/libc++.so.1: unsupported file layout /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/nothing_to_do.pass.cpp failed to compile Compile line was: clang++ -m32 -DCOMPAT_32BIT -stdlib=libc++ -O2 -pipe -mtune=generic -std=c++11 -stdlib=libc++ -I/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/support -I/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/include -L/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib nothing_to_do.pass.cpp -lm failed 1 tests in /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib/libc++.so.1: unsupported file layout /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/algorithms/version.pass.cpp failed to compile Compile line was: clang++ -m32 -DCOMPAT_32BIT -stdlib=libc++ -O2 -pipe -mtune=generic -std=c++11 -stdlib=libc++ -I/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/support -I/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/include -L/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib version.pass.cpp -lm failed 1 tests in /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/algorithms /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib/libc++.so.1: unsupported file layout /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/algorithms/alg.c.library/tested_elsewhere.pass.cpp failed to compile Compile line was: clang++ -m32 -DCOMPAT_32BIT -stdlib=libc++ -O2 -pipe -mtune=generic -std=c++11 -stdlib=libc++ -I/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/support -I/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/include -L/var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib tested_elsewhere.pass.cpp -lm failed 1 tests in /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/test/algorithms/alg.c.library /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999-x86_fbsd/lib/libc++.so.1: unsupported file layout <snip>
Created attachment 352590 [details, diff] test phase, sample patch for libcxx-9999.ebuild
Created attachment 352596 [details, diff] add pkg_setup(), sample patch for libcxx-9999.ebuild In addition, I think better to add check of CXX before libcxx compiling. * If you want using gcc, gcc-4.7 or later required. * USE=-libcxxrt is set, need to use gcc to compile. * USE=libcxxrt is set, I have confirmed that compile can be successfully in both clang and gcc. Of course, it works fine ;-) gcc-4.6.3, USE="-libcxxrt -static-libs") # USE=-libcxxrt ebuild libcxx-9999.ebuild digest clean compile gmake -j1 shared x86_64-gentoo-freebsd9.0-g++ -I../include -D__GLIBCXX__ -I/usr/lib/gcc/x86_64-gentoo-freebsd9.0/4.6.3/include/g++-v4 -I/usr/lib/gcc/x86_64-gentoo-freebsd9.0/4.6.3/include/g++-v4/x86_64-gentoo-freebsd9.0 -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -fPIC -nostdinc++ -c ../src/debug.cpp -o debug.So cc1plus: error: unrecognized command line option '-std=c++11' gcc-4.7.2, USE="-libcxxrt -static-libs") <snip> x86_64-gentoo-freebsd9.0-g++ -I../include -D__GLIBCXX__ -I/usr/lib/gcc/x86_64-gentoo-freebsd9.0/4.7.2/include/g++-v4 -I/usr/lib/gcc/x86_64-gentoo-freebsd9.0/4.7.2/include/g++-v4/x86_64-gentoo-freebsd9.0 -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -fPIC -nostdinc++ -c ../src/algorithm.cpp -o algorithm.So x86_64-gentoo-freebsd9.0-g++ -fPIC -nodefaultlibs -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wl,-z,defs -shared -Wl,-soname,libc++.so.1 -o libc++.so.1.0 debug.So hash.So regex.So memory.So bind.So utility.So mutex.So valarray.So stdexcept.So condition_variable.So ios.So typeinfo.So string.So iostream.So exception.So system_error.So strstream.So chrono.So future.So thread.So locale.So new.So random.So algorithm.So -lsupc++ -lpthread -lrt -lc -lgcc_s ln -s libc++.so.1.0 libc++.so.1 ln -s libc++.so.1 libc++.so >>> Source compiled. gcc-4.7.2, USE="libcxxrt -static-libs") <snip> x86_64-gentoo-freebsd9.0-g++ -I../include -DLIBCXXRT -I/usr/include/libcxxrt/ -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -fPIC -nostdinc++ -c ../src/algorithm.cpp -o algorithm.So x86_64-gentoo-freebsd9.0-g++ -fPIC -nodefaultlibs -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wl,-z,defs -shared -Wl,-soname,libc++.so.1 -o libc++.so.1.0 debug.So hash.So regex.So memory.So bind.So utility.So mutex.So valarray.So stdexcept.So condition_variable.So ios.So typeinfo.So string.So iostream.So exception.So system_error.So strstream.So chrono.So future.So thread.So locale.So new.So random.So algorithm.So -lcxxrt -lpthread -lrt -lc -lgcc_s ln -s libc++.so.1.0 libc++.so.1 ln -s libc++.so.1 libc++.so >>> Source compiled. clang-3.3, USE="-libcxxrt -static-libs") <snip> clang++ -I../include -D__GLIBCXX__ -I/usr/include/c++/4.2 -I/usr/include/c++/4.2/backward -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -fPIC -nostdinc++ -c ../src/algorithm.cpp -o algorithm.So clang++ -fPIC -nodefaultlibs -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wl,-z,defs -shared -Wl,-soname,libc++.so.1 -o libc++.so.1.0 debug.So hash.So regex.So memory.So bind.So utility.So mutex.So valarray.So stdexcept.So condition_variable.So ios.So typeinfo.So string.So iostream.So exception.So system_error.So strstream.So chrono.So future.So thread.So locale.So new.So random.So algorithm.So -lsupc++ -lpthread -lrt -lc -lgcc_s /usr/bin/x86_64-gentoo-freebsd9.0-ld: cannot find -lsupc++ clang: error: linker command failed with exit code 1 (use -v to see invocation) gmake: *** [libc++.so.1.0] Error 1 * ERROR: sys-libs/libcxx-9999 failed (compile phase): clang-3.3, USE="libcxxrt -static-libs") <snip> clang++ -I../include -DLIBCXXRT -I/usr/include/libcxxrt/ -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -fPIC -nostdinc++ -c ../src/algorithm.cpp -o algorithm.So clang++ -fPIC -nodefaultlibs -O2 -pipe -std=c++11 -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -Wl,-z,defs -shared -Wl,-soname,libc++.so.1 -o libc++.so.1.0 debug.So hash.So regex.So memory.So bind.So utility.So mutex.So valarray.So stdexcept.So condition_variable.So ios.So typeinfo.So string.So iostream.So exception.So system_error.So strstream.So chrono.So future.So thread.So locale.So new.So random.So algorithm.So -lcxxrt -lpthread -lrt -lc -lgcc_s ln -s libc++.so.1.0 libc++.so.1 ln -s libc++.so.1 libc++.so >>> Source compiled.
(In reply to Michał Górny from comment #24) > I wonder if PMS cares about it. Theoretically speaking, you may sometimes > end up with duplicate IUSE values e.g. due to two eclasses defining the same > IUSE. If multiple flags are fine for all PMs, I would say leave them. No > point in removing duplicates if PM does that run anyway. Okey; so are you fine with me applying this patch then ? OTOH, thinking more about it, all this is because we want to avoid code duplication and set the flags in only one place. If it becomes a pain and code to do it right is more complicated we can just define IUSE and MULTILIB_USEDEP manually without duplication. I don't expect them to grow much anyway.
(In reply to Yuta SATOH from comment #26) > Created attachment 352590 [details, diff] [details, diff] > test phase, sample patch for libcxx-9999.ebuild errm the point here was to avoid special casing x86_fbsd; this doesnt really scale :/
Comment on attachment 352596 [details, diff] add pkg_setup(), sample patch for libcxx-9999.ebuild >diff --git a/libcxx-9999.ebuild b/libcxx-9999.ebuild >index abffa7b..090f462 100644 >+pkg_setup() { >+ if ! use libcxxrt && [[ $(tc-getCC) != *gcc* ]] ; then getCXX and g++ I'd say. IIRC libcxx doesnt need CC. >+ eerror "Please set gcc, g++ to CC, CXX." >+ eerror >+ die >+ fi >+ if [[ $(gcc-version) < 4.7 ]] && [[ $(tc-getCXX) != *clang++* ]] ; then >+ if use libcxxrt && has_version sys-devel/clang ; then >+ ewarn "Because version of gcc is old, force set CC=clang, CXX=clang++." >+ ewarn >+ ewarn "If you want to compile it using gcc, please install gcc-4.7 or later." >+ ewarn "Don't forget to switch to latest gcc using gcc-config." >+ >+ export CC=clang >+ export CXX=clang++ or maybe just s/c++11/c++0x/ in the makefile instead of forcing this. I remember gcc 4.6 not being able to build libcxx, or even miscompiling it though.
(In reply to Alexis Ballier from comment #29) > (In reply to Yuta SATOH from comment #26) > > Created attachment 352590 [details, diff] [details, diff] [details, diff] > > test phase, sample patch for libcxx-9999.ebuild > > errm the point here was to avoid special casing x86_fbsd; this doesnt really > scale :/ I understand that this dirty patch is not good. but, I don't have a good idea at this time... (In reply to Alexis Ballier from comment #30) > Comment on attachment 352596 [details, diff] [details, diff] > add pkg_setup(), sample patch for libcxx-9999.ebuild > > >diff --git a/libcxx-9999.ebuild b/libcxx-9999.ebuild > >index abffa7b..090f462 100644 > >+pkg_setup() { > >+ if ! use libcxxrt && [[ $(tc-getCC) != *gcc* ]] ; then > > getCXX and g++ I'd say. IIRC libcxx doesnt need CC. ok, how about this? [[ $(tc-getCXX) == *g++* && $(tc-getCXX) != *clang++* ]] > or maybe just s/c++11/c++0x/ in the makefile instead of forcing this. > I remember gcc 4.6 not being able to build libcxx, or even miscompiling it > though. If you use gcc-4.6, compile will fail. http://llvm.org/bugs/show_bug.cgi?id=15182 FYI, >>> Compiling source in /var/tmp/portage/sys-libs/libcxx-9999/work/libcxx-9999 ... * amd64_fbsd: running multilib-minimal_abi_src_compile gmake -j1 shared x86_64-gentoo-freebsd9.0-g++-4.6.3 -I../include -DLIBCXXRT -I/usr/include/libcxxrt/ -O2 -pipe -std=c++0x -fstrict-aliasing -Wall -Wextra -Wshadow -Wconversion -Wpadded -Wstrict-aliasing=2 -Wstrict-overflow=4 -fPIC -nostdinc++ -c ../src/debug.cpp -o debug.So In file included from ../include/functional:465:0, from ../src/debug.cpp:13: ../include/memory:2482:49: error: function 'std::__1::default_delete<_Tp>::default_delete()' defaulted on its first declaration must not have an exception-specification ../include/memory:2502:49: error: function 'std::__1::default_delete<_Tp []>::default_delete()' defaulted on its first declaration must not have an exception-specification gmake: *** [debug.So] Error 1 * ERROR: sys-libs/libcxx-9999 failed (compile phase): * emake failed
(In reply to Yuta SATOH from comment #31) > (In reply to Alexis Ballier from comment #30) > > Comment on attachment 352596 [details, diff] [details, diff] [details, diff] > > add pkg_setup(), sample patch for libcxx-9999.ebuild > > > > >diff --git a/libcxx-9999.ebuild b/libcxx-9999.ebuild > > >index abffa7b..090f462 100644 > > >+pkg_setup() { > > >+ if ! use libcxxrt && [[ $(tc-getCC) != *gcc* ]] ; then > > > > getCXX and g++ I'd say. IIRC libcxx doesnt need CC. > > ok, how about this? > [[ $(tc-getCXX) == *g++* && $(tc-getCXX) != *clang++* ]] oops, yes right, it seems simpler with gcc indeed :) > > or maybe just s/c++11/c++0x/ in the makefile instead of forcing this. > > I remember gcc 4.6 not being able to build libcxx, or even miscompiling it > > though. > > If you use gcc-4.6, compile will fail. > http://llvm.org/bugs/show_bug.cgi?id=15182 > > FYI, Ok, thanks
Comment on attachment 352596 [details, diff] add pkg_setup(), sample patch for libcxx-9999.ebuild Applied something in those lines to -9999, thanks.
Comment on attachment 352308 [details, diff] patch for multilib-build.eclass applied this one then
Comment on attachment 352314 [details, diff] patch for amd64/9.1/clang profile applied this one (but for the regular profile too), thanks
+ 26 Aug 2013; Alexis Ballier <aballier@gentoo.org> + freebsd-libexec-9.2_rc3.ebuild, +files/freebsd-libexec-9.2-no_ld32.patch: + Use LD_* variables for 32bits too instead of the FreeBSD invention LD_32_*. + We use LD_* everywhere on Gentoo and things like libtool wrappers have no + clue + about LD_32_* and thus fail to run from the build directory. + -> this should fix the 32bits failure of libcxx/cxxrt, closing since this should have been the last bits.
