[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

dpkg build under Mac OS X failed



(I wrote Raphael earlier and am writing again after taking what he said
into account.)

I tried to build dpkg from source under Mac OS X 10.6.8, and succeeded
only by

altering  dpkg-linker.m4 to remove the -O1 flag the Apple linker ld didn't
understand
getting newer versions of autotools
using the -i flag for autoreconf

It would have been very helpful if there had been a README or INSTALL with
instructions,
particularly the prerequisites and procedures for building dpkg.    Surely
a package manager should not expect the presence of a package manager to
figure out dependencies.  Also I didn't know which branch of the git
repository I wanted (but I used master, thinking that's what Raphael
recommended).

*****

details of what I did:

git clone git://git.debian.org/git/dpkg/dpkg.git
autoreconf  - which gave a number of messages about missing AM_* macros
and problems in the dpkg m4 scripts about DPKG_* being required but not
defun'd .   This was from autoconf 2.6.1, automake 1.10, m4 1.4.6, libtool
Apple Computer, Inc. version cctools-795, which were what was on the
system, possibly from installing Xcode 3.2.6.

I had later versions of autotools (autoconf 2.68, automake 1.11, m4
1.4.16, libtool 2.4) on the system though not in the path at the time of
running autoreconf above.  When I included them in the path, which also
included perl 5.14.1 (the default on the mac is 5.10.0), having newly
re-config'd, made, and installed them in the presence of that perl (which
was not built with threads enabled; something about which they had
complained before they were rebuilt), and also in the presence of other
newer software versions too numerous to describe now, an autoreconf for
dpkg complained only about some missing files in build-aux.

Then, using the -i flag for autoreconf, there were no errors.  Then
(unsure of what to do) I ran autoheader and automake, ./configure
--prefix=/usr/local/unix all of which went Ok, and make, which went Ok
until it came to linking I think: the output showed CC build.o, extract.o,
info.o, main.o, then CCLD dpkg-deb resulted in ld: unknown option: -O1.

The version of ld is @(#)PROGRAM:ld  PROJECT:ld64-97.17
llvm version 2.9svn, from Apple Clang 1.7 (build 77)

Perhaps wrongly, I wasn't motivated to find a newer version of ld. 
Already I'd had a problem when making new binutils that the new ar and
ranlib apparently couldn't read the magic numbers right, so that I had to
use the original apple versions (or get into their source code).

So, in m4/dpkg-linker.m4 I removed the -O1 flag from the default LDFLAGS,
re-ran autoreconf etc., and everything build and installed Ok.  dpkg
--help worked, but at this point I had no further need for dpkg, since I'd
already dealt manually with the dependencies for building a number of
packages from source.

make check doesn't get past CCLD t-test, which has an undefined symbol
_libintl_gettext.  There
had been no gettext on the system, but I build that, and the necessary
symbol seems to be defined
(according to nm) in the libintl.a and libintl.dylib in a directory I
tried to tell the linker about via LDFLAGS, but apparently I haven't
discovered the right way to let the dpkg build system know about it.  My
time for this has run out now.

Thank you all for your work on dpkg.


Reply to: