* Mathieu Desnoyers <[email protected]> wrote: > ----- Original Message ----- > > From: "Jon Bernard" <[email protected]> > > To: "Mathieu Desnoyers" <[email protected]> > > Cc: "Ondřej Surý" <[email protected]>, "Michael Jeanson" > > <[email protected]>, "lttng-dev" > > <[email protected]> > > Sent: Tuesday, May 27, 2014 9:18:27 PM > > Subject: Re: Debian specific userspace RCU configure override > > > > * Mathieu Desnoyers <[email protected]> wrote: > > > ----- Original Message ----- > > > > From: "Jon Bernard" <[email protected]> > > > > To: "Ondřej Surý" <[email protected]> > > > > Cc: "Mathieu Desnoyers" <[email protected]>, "Michael > > > > Jeanson" <[email protected]>, "lttng-dev" > > > > <[email protected]> > > > > Sent: Tuesday, May 27, 2014 4:18:48 PM > > > > Subject: Re: Debian specific userspace RCU configure override > > > > > > > > * Ondřej Surý <[email protected]> wrote: > > > > > On Sun, May 25, 2014, at 2:59, Mathieu Desnoyers wrote: > > > > > > Why are each package compiled against completely different targets ? > > > > > > > > > > urcu invokes ./configure manually while ltt-control uses > > > > > dh_auto_configure wrapper and that makes the difference > > > > > > > > This is correct. When I first saw the difference, I assumed they would > > > > both invoke configure in a way that wouldn't effect the target. But now > > > > I remember having a similar problem on sparc (which is why urcu includes > > > > this override) where the target discovery was not correct. > > > > > > > > It looks to me like a bug related to debhelper (which provides > > > > dh_auto_configure). For now, I think this override applied to > > > > lttng-tools will correctly fix the build without disabling dmb. I will > > > > let the existing transition into testing complete and then submit new > > > > packages. > > > > > > The big question here: is it OK to generate "dmb" instruction ? If the > > > intent of this architecture support is to cover earlier-than-armv7 ARM > > > processors, then "dmb" should not be explicitly generated, and therefore > > > URCU configuration would need fixing. If the intent of this Debian arch > > > is to cover only ARMv7 and better, then it's lttng-tools that needs > > > fixing. > > > > So my assumption was wrong, debian armel targets armv4t (armhf targets > > v7). The build machines happen to be running a v7 kernel, but the build > > must honor the target which is 'arm-unknown-linux-gnueabi' in this case > > (implying no dmb instructions). > > > > So, lttng-tools (which uses the dh wrapper) is correctly detecting the > > build target. This is because it's calling autoreconf and passing > > additional '--build' and '--host' parameters to ./configure. If > > I change liburcu to use this wrapper by removing the explicit configure > > override, it too detects the correct build target and disables dmb > > instructions as it should. > > > > So two things come to mind: > > > > 1. Technically, upstream doesn't need to do anything for this change > > to correctly resolve the existing issues in Debian. But it does > > mean that non-debian arm builds may discover an incorrect build > > target and produce incompatible object code if the user doesn't > > regenerate the build system files and call configure in a similar > > way. Personally, I would like to see this fixed for everyone, so > > a fix to both urcu and lttng-tools configure scripts seems > > appropriate. I'm more than happy to test any patches on the > > resources to which I have access. > > I'm afraid I don't understand what would need fixing in upstream urcu > and lttng-tools. If two packages are built for different architectures > (older ARM vs ARMv7+), I don't see how anyone would expect that both > packages would be compatible.
As I currently understand, the debian build problem is that although the package is compiled on armv7 hardware, it is expected to target armv4t. And this is not correctly detected at configure-time. The folks on #debian-arm suggested that this could be solved in configure.ac. I can explicitly pass '--build <target>' to ./configure to get around this, but arm users that build from source will need to remember this. Also, this bug [1] was just filed which is related, I'm curious of your thoughts on this. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749586 > > > > 2. Using the dh wrapper is considered best-practice, so liburcu > > should be conforming to this. I need to re-test the change on > > sparc and make sure I'm not in a world of hurt. > > The issue here seems to be caused by the sparc build of urcu. Perhaps > the override could be done only for sparc ? It is a bit special (see > urcu README file for details). Agreed, I'll revisit sparc and see where things stand after a consensus is reached on the other topics. Cheers, -- Jon _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
