[Glibc-bsd-devel] GNU/kFreeBSD and package report

[Robert Millan]

On Fri, Jul 02, 2004 at 05:23:59PM +0000, Brian M. Carlson wrote:
> > > krb4 (builds with db4.2; currently uses db4.1, which is not in
> > > archive)
> >
> > db4.1 should work. Perhaps it needs a libtool/autotools update (which
> > is non trivial in its weird build system) but that should be all.
> 
> db4.1 requires java to build, and we don't have java. So either 
> debian/control needs to be modified or we need to get java (which 
> requires libffi2).

Defintely we need java, then. Do you mean a JVM like kaffe or the gcj
compiler?

> > If you like, you can backport the changes in gcc-3.4 (by differing
> > from the gcccvs SVN repository) to gcc-3.2 and gcc-3.3, but I find
> > more useful to spend effort getting gcc-3.4 in shape rather than
> > this.
> 
> Should we modify gcc-defaults to make it the default on kfreebsd-gnu?

No. We used to have gcc-3.4 as default and that brought lots of trouble.
This is why I hacked gcc-3.2 and gcc-3.3 to build for us with minimal options.

We might just get gcc-3.3 in shape with all options like libffi or gcj, but
if sarge is released soon (read: GR results) then gcc-3.4 will be made
default for all platforms soon also, so we wouldn't need to care about 3.3
anymore. Let's see the GR results tonite..

> > Currently gcc-3.4 (in experimental) still won't build but it's mostly
> > fixed. There was a problem with our selection of conditional patches
> > not being compatible. Would you like to give it a try?
> 
> I'll see what I can do. I won't have access this weekend (July 4 is the 
> US Independence Day which I am spending with family) but if not this 
> weekend, then next week probably.

Ok. If you send a patch to the BTS for gcc-3.4, drop me a note (I have
commit rights to gcccvs SVN repository).

> I'd like to get subversion working 
> first, so I can pull patches directly into the system.

This is what you wanted neon for? Well porting subversion opens a whole can of
worms, since its dependency tree has an horrible tendency to expand and expand.

You'll need an ocaml compiler among other things. Before you attempt to
port ocaml, look at the bug in BTS. I discussed portability with the
maintainer before and there are some useful notes.

> > Build-Depends: ..., vim | not+linux-gnu, ...
> 
> ITYM, libgpmg1 | not+linux-gnu. A bug has been filed.

Ah yes, of course. Btw, for these kind of trivial bugs sending a patch and
adding the patch tag sometimes helps a lot (to prevent the maintainer from
ignoring our report).

> > > krb5 (can't find res_search in -lresolv)
> >
> > Ah, the mithical res_search thing. Guillem fixed some of these bugs
> > IIRC.
> 
> OK. There is a __res_search, though.

Something related with macros IIRC. Have you looked at Guillem's patch?

> > > postgresql (no template for kfreebsd-i386)
> >
> > What do you mean here?
> 
> The postgresql build system uses autotools to select some template that 
> it then uses for building somehow. There is no template for 
> i386-unknown-kfreebsd5.2.1-gnu or i386-pc-kfreebsd-gnu.

I'll have a look.

> I'd also like to point out that we are now more popular (according to 
> popcon) than both s390 and hurd-i386.

Yeah well. popcon is not very reliable for comparing unpopular archs, but
it's fun to see it anyway :).

> In addition, imlib+png2 builds with libpng12-dev (which is the old 
> libpng3) and also it fails linking looking for XFreePixmap (and a host 
> of other X* functions). I'll post a build log soon.

Maybe missing -l flag? I found some problems with linker dependencies not
being automaticaly resolved for a few xlibs (in tetex-bin or tetex-base IIRC).

-- 
Robert Millan

"[..] but the delight and pride of Aule is in the deed of making, and in the
thing made, and neither in possession nor in his own mastery; wherefore he
gives and hoards not, and is free from care, passing ever on to some new work."

 -- J.R.R.T., Ainulindale (Silmarillion)