Just one thought: Why not test "-Wl,--as-needed" too? It should greatly reduce the number of dependencies for most packages without the tedious and error-prone task to re-libtoolize the package for every new release.
I'd also like to know how many percent of our packages which could be re-libtoolized actually are re-libtolized (my guess is < 20%) and if we can do something to improve the situation. Cheers, Bastian Loïc Minier schrieb: > Hi there, > > (We had a small exchange via private email with Lucas and he suggested > we continue the discussion on debian-qa@, hence full text included > below.) > > On Mon, Feb 26, 2007, Lucas Nussbaum wrote: >> On 24/02/07 at 16:34 +0100, Loïc Minier wrote: >>> Hi, >>> >>> I've been rebuilding the GNOME stack with a couple of interesting QA >>> tests: >>> - -Os in CFLAGS >>> - -Wl,-O1 in LDFLAGS >>> - -Wl,-z,defs in LDFLAGS >>> - -j2 in MAKEFLAGS >>> - use differents directories for builddir and srcdir >>> >>> Not all these tests are easily achieved with Debian packages. It was >>> easier for me because I didn't dpkg-buildpackage these, I used a >>> GNOME tool named jhbuild instead. >>> >>> These tests would be however interesting for Debian packages: >>> - -Os is useful for embedded platforms >>> - -Wl,-O1 gives better performances and might be promoted for all >>> packages at some point >>> - -Wl,-z,defs checks for missing link flags; this is a very useful test >>> but it breaks with Python extensions >>> - -j2 is interesting to catch errors in Makefiles and might be used in >>> the future to speed up builds >>> >>> One way to easily test these flags might be to use wrappers for cc, >>> gcc, c++, g++..., adding the flags. >> The main problem with testing -Os, -Wl,-O1 and -Wl,-z,defs is that they >> could cause the compiler/linker to generate incorrect code instead of >> just failing, and this is much harder to detect. > > I think -Os and -Wl,-O1 are more about testing our toolchain, but I > think it's interesting to check whether this works on a large scale or > in e.g. the GNOME stack because this has some direct benefit for people > interested in the use of these flags and because it will improve our > toolchain. I agree it might also produce broken binaries and that it > would be hard to test, but it's a good first step into ensuring we > could provide a "thin client optimized" archive for example. > > -Wl,-z,defs shouldn't cause any incorrect binaries; it should simply > prevent the build in interesting cases, that is when some link flags > are missing. The most problematic packages with -z defs are Python > bindings which explicitely avoid linking to -lpython since the python > interpreter is not linked to libpython, but provides the same symbols. > >> make -j2 looks really interesting. > > Yes; I expect it will expose some rare Makefile races (rare is in the > context of GNOME since all modules are mostly automakized; other > upstreams might have broken Makefiles :-) but it will certainly help us > work toward building with parallel=$i, and I'm sure you would benefit > of that! > >> Are you interested in working with me on that ? > > Well, I've got the tools to do the work over GNOME (jhbuild), and I'm > busy enough that I'd prefer avoiding putting my finger in more general > QA stuff. O:-) These were mostly suggestions as a followup to your > request during your talk at FOSDEM of what tests you could run; it > seemed you were requesting more ideas to keep more nodes busy. :) > -- Bastian Venthur http://venthur.de Debian Developer venthur at debian org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
