----- 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. > > 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). Thoughts ? Thanks, Mathieu > > Thoughts? > > -- > Jon > -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
