On Mon, 19 Jan 2009 15:23:33 +0100
"Martin Fuzzey" <mfuzzey@gmail.com> wrote:
> Attached are emdebian patch files for ltrace and its dependency libelf.
Thanks!
> They build ok and run on target.
>
> A few points I'm not quite sure on:
>
> In ltrace:
> =======
> ltrace initially failed to cross build as it used uname -m in a sub
> makefile (sysdeps/linux-gnu/Makefile) to build architecture dependent
> code.
> I added a debian/patches/99_emdebian_no_auto_arch_detect.patch to fix
> this by using DEB_HOST_ARCH
>
> -ARCH := $(shell uname -m | sed -e s/i.86/i386/ -e
> s/sun4u/sparc64/ \
> - -e s/arm.*/arm/ -e s/sa110/arm/ -e
> s/ppc64/ppc/ -e s/s390x/s390/)
> +ARCH := $(DEB_HOST_ARCH)
That sounds like a bug in ltrace - it should use dpkg-architecture and
decide whether it wants DEB_HOST_ARCH or DEB_BUILD_ARCH. I'll look into
that more closely once Lenny is released and I start the Code Audit
that will seek to get all these patches into the relevant Debian
packages (which in turn will make it a lot easier to get Crush for
armel, mips and the rest).
> However the Makefile also contains a clean target that uses ARCH.
> Since clean is called by debuild after unpatching it was cleaning the
> build machine arch not the target arch which caused dpkg-source to
> fail on the second build.
>
> To fix this I call the correct clean target from debian/rules too:
> +clean::
> + # sysdeps/linux-gnu/Makefile clean has been unpatched so
> assumes build ARCH
> + $(MAKE) -C sysdeps/linux-gnu/$(DEB_HOST_ARCH) clean
> +
Using the same fix for both is definitely correct - as is ensuring that
the package builds twice in a row, even cross-.
Once I resolve the underlying issue with the ltrace maintainer, the
same fix can be used for both.
> in libelf:
> ======
> It uses a configure file generated by autoconf 2.13 and
> autotools-dev/README.Debian.gz states
>
> cross-compiling with autoconf 2.13 is an Evil art, which shall turn sane and
> bright minds into quivering wrecks upon contact with the madness that lies in
> that path.
:-)
No wonder autoconf2-13 is described as "obsolete version".
> I basically copied the existing rxvt package for this - it seems to
> work and i'm not (yet) a quivering wreck :)
>
> hope this is ok (changing autconf versions seems more like a job for
> the debian package not emdebian patches)
Needs must. Sometimes the autotools have to be radically modified for
Crush - it becomes essential if you are going to use --disable-foo
instead of --enable-foo in the debian/rules configure target in order
to modify functionality and drop dependencies.
> Something odd in I18N: it was shipping a compiled gmo file rather than
> generating it from the po.
The .gmo was compiled upstream? That sounds like a bug in the Debian
packaging - the .gmo should be cleaned out and a new one built from
the .po.
> It was also preserving this file
> (po/de.gmo) in debian/rules by backing it up in build: and restoring
> it in clean:
eh?
Always worth testing those with native builds. Add a target the removes
all .gmo files and rebuild. Builds fine for me:
rm po/*.gmo
# mv po/de.gmo po/de.gmo.orig
# cp po/de.gmo.orig po/de.gmo
> This worked ok for the first build but em_installtdeb removed the
> file causing the backup made on the next build to fail.
OK, I'll look at that - my preferred method is to ensure that the
backup is never made, used or tested.
> I just patched debian/rules to remove the file and generate it each
> time [the generated one is identical to the shipped one]
Even more weird.
> It looks like po/Makefile can compile a helper program however this is
> not used when gettext is available.
autoconf nastiness probably - there should be a Makefile.in.in in po/ -
a symlink to /usr/share/intltool/Makefile.in.in
libelf looks like a really old package - probably in need of a
refreshed autotools config with autoreconf -fs upstream.
Thanks for your work on these two!
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpbhJqKcJXR_.pgp
Description: PGP signature