On Sat, 2011-05-28 at 01:37 +0100, peter green wrote: > > > > Unfortunately it seems while the build was sucessful the binary > > packages are incomplete and unusable. Further research is needed into > > why things are breaking. > Ok nailed that issue, it seems that at some point during the build > process debian/control was regenerated from debian/control.in undoing my > changes.
Yes the debian/control is generated from debian/control.in using the
fixdeb script executed at the beginning of the build process. The reason
the debian/control is kept is because dpkg-buildpackage refuses to run
if it does not find it at the beginning of the build process.
I admit this is tricky, but it allows creating packages with an
arbitrary suffix in ${PACKAGESUFFIX}.
> I've also discovered that grab_vcsa seems to be linux specific so i've
> added fixes to debian/rules to exclude that. Likewise for serveral
> "packages"
> (in the fpc sense not the debian sense) that don't seem to be built when
> building for freebsd (I dunno if this is because they can't be built on
> freebsd
> or simply because upstream doesn't think them appropriate to build on
> freebsd).
In this case these are not supposed to be packaged, or you should send
individual patches to upstream. Please open bugs reports on
http://bugs.freepascal.org and attach you patches.
> That allowed me to build arch specific binary packages that for work for
> freepascal programs that didn't link against libc but any freepascal
> program that used libc would fail to link, I attempted to fix that up by
> hacking the freebsd rtl in a couple of places to be like the linux rtl
> but failed. I may take another look at this but I suspect it will need
> someone with assembler knowlage to solve.
I don't think I can help here, but Marco for sure. Please answer his
question.
> A new patch for the debian stuff with the above fixes is included as are
> my attempts at fixing the libc link issue in the freebsd rtl but until
> we get the libc link issue sorted it's IMO not suitable for inclusion in
> debian. It would probablly also make sense to make kfreebsd it's own
> target rather than hacking the freebsd RTL in place.
I would prefer to modify upstream make files using a
debian/patches/*.diff to harmonize linux a kfreebsd paths and then
submit these patches to upstream instead of hacking the debian/rules and
debian/moveexamples.
Anyway I'm looking more deeply on your patches and will select some of
them to be integrated. I don't have the time now, but I'll see if I can
afford a kfreebsd installation on my linux box, replacing gnu-hurd as I
never managed to make it boot on my machine.
Cheers.
signature.asc
Description: This is a digitally signed message part
