-----Message d'origine----- Date: Wed, 2 Oct 2013 19:07:56 +0000 >> Closing observations: >> >> What's the best, easiest way to get the 32-bit versions of popt and uuid? > > Some -dev packages are also multiarch, for example I can install > libpopt-dev:amd64 and libpopt-dev:i386 at the same time (on Ubuntu > 13.10) and get the "real" .so symlink from the package. > > It doesn't seem to be the case with uuid-dev though, I can only have one > version installed at a time. But you can install one, compile what you > need, then switch to the other one. > > ia32-libs has long been deprecated, it now simply depends on a bunch of :i386 > libraries. What's sad is that it used to contain both the > libraries and the headers (so the equivalent of the -dev packages) it > shipped, whereas now the cross-arch dev files are a bit harder to get.
Yeah, that situation is an absolute mess right now. There apparently was a ppa with a 'getlibs' package that did precisely what is needed here: bolting 32-bit libraries onto a x86-64 system. Sadly, the original ppa is gone, and I can only find scattered updates that go no further than Ubuntu Natty, apparently. >> My lttng-tools-32 make ran into trouble with the 'tests/unit' >> subdirectory (error below). Is this an actual bug? >> >> Why did the lttng-tools make not restrict itself to the lttng-consumerd >> daemon as requested? > > These could be bugs in the build system. It's quite an obscure feature, so > it's not as well-tested... I tried this in a pure 64-bit context and the same error occurred. I'm filing a bug. >> Couldn't the lttng-tools build detect it's running in a 64-bit system and >> at least try to make a proper 32-bit consumer daemon (and supporting >> libraries)? Maybe this could be a configure switch, off by default. > > This is hard to do with the current build system. Autotools basically lets > you "build this one thing". If you want to build something 64 bits, > and then something 32 bits, you have to run 'make' twice. And packaging the > result is a nightmare. Agreed, not worth the trouble. >> In building the 32-bit consumer daemon, could we skip the >> with-consumerd64-* options? > > You can probably skip those. They are used for the opposite case, where you > want to compile a 32-bit daemon that will use a 64-bit consumer. > The Debian/Ubuntu packages for liblttng-ust and liburcu are > multiarch-enabled, so you can install the :i386 and :amd64 versions in > parallel. That way they will be tracked by the package manager, and won't > "linger around". Except that the Ubuntu LTTng packages are hopelessly behind right now. I wanted to do everything with the 2.3.0 release. ################################################# On a different note, why does LTTng have 32- and 64-bit consumers anyway? The only possible difference between a 32-bit tracer and a 64-bit tracer is that the latter could generate event record fields that are 64-bit longs and floats, while the former cannot (but will never have to, since the application it is tracing won't have such beasts anyway). So the 64-bit consumer should be backward compatible with the 32-bit consumer, because it deals with a super-set of the 32-bit consumer requirements. If this were the only difference, LTTng would not need a separate 32-bit consumer daemon. Is there some sort of context-switching overhead associated with a 64-bit daemon accessing a buffer that exists in a 32-bit process context? The performance gain would justify the existence of a 32-bit consumer, I suppose. Daniel U. Thibault Protection des systèmes et contremesures (PSC) | Systems Protection & Countermeasures (SPC) Cyber sécurité pour les missions essentielles (CME) | Mission Critical Cyber Security (MCCS) R & D pour la défense Canada - Valcartier (RDDC Valcartier) | Defence R&D Canada - Valcartier (DRDC Valcartier) 2459 route de la Bravoure Québec QC G3J 1X5 CANADA Vox : (418) 844-4000 x4245 Fax : (418) 844-4538 NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ> Gouvernement du Canada | Government of Canada <http://www.valcartier.drdc-rddc.gc.ca/> _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
