Hi, On 09/05/2016 08:33 PM, Christian Seiler wrote: > On 09/05/2016 07:20 PM, Andrey Rahmatullin wrote: >> On Mon, Sep 05, 2016 at 07:07:51PM +0200, Muri Nicanor wrote: >>> so, i've got my first two FTBFS bugs (on mips and hppa)- what the >>> recommended way of testing fixes for architectures i don't have >>> testmachines of? >> Porterboxes. See https://dsa.debian.org/doc/guest-account/ about getting >> access for non-DDs. > > Note that there are no official hppa porterboxes. You can ask on > the debian-hppa mailing list for access to an unofficial one > though. > > But speaking of the bugs, they don't actually require porterbox > access. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836713 > > The hppa build chroots don't have systemd installed (for > whatever reasaon), in contrast to chroots on most other > architectures. > > Since you depend on systemd.pc, which is part of the > systemd package, just Build-Depend on systemd to make > systemd.pc available. You won't need porterbox access > to fix that issue. (Btw. libsystemd.pc != systemd.pc) ah, that comment in paranthesis helped me to understand the problem ;) i was looking at the wrong package and was wondering what to do, because there is no official libsystemd-dev package for hppa. thanks for pointing that out! ;) > Also note that there are plans to make init non-Essential > in the future, so more build chroots will not have > systemd preinstalled in them, so the problem you're seeing > on hppa now is going to be a problem on all archs sooner > or later. ok, thanks for the hint! > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836712 > > MIPS (at least 32bit) doesn't support 64bit atomic > operations intrinsically (_8 == 8 bytes) - and your software > uses std::atomic<uint64_t> (found that by grepping). > > However, gcc provides an emulation library called libatomic. > You should link against that emulation library if present > in order to use those intrinsics. aha, thanks for the explanation! that makes the situation a lot clearer. > I've attached a patch against your package (add it as a quilt > patch) that checks for the availability of libatomic and adds > it to the linker flags. This might result in a spurious > dependency on libatomic on other platforms, but unfortunately > I don't know of any way to properly pass --as-needed for just > this library without libtool reordering the entire list of > linker flags. :-( thanks a lot! i'll integrate that asap and relay it to upstream. cheers, -- muri
Attachment:
signature.asc
Description: OpenPGP digital signature