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

Re: Bug#622365: Fix FTBFS of tofrodos for GNU/Hurd



On Sat, 2011-04-16 at 02:42 +0200, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2011-04-12 at 21:46:09 +0200, Svante Signell wrote:
> > Final version??
> 
> > diff -ur tofrodos-1.7.8.debian.1/src/tofrodos.c tofrodos-1.7.8.debian.1.new/src/tofrodos.c
> > --- tofrodos-1.7.8.debian.1/src/tofrodos.c	2011-04-12 18:21:50.000000000 +0200
> > +++ tofrodos-1.7.8.debian.1/src/tofrodos.c.new	2011-04-12 21:24:27.000000000 +0200
> > @@ -14,7 +14,9 @@
> >  #include <stdlib.h>	/* EXIT_SUCCESS, mkstemp() in some systems */
> >  #include <string.h>	/* strrchr(), strlen(), strcpy(), strcat() */
> >  #include <sys/stat.h>	/* stat() */
> > -
> > +#ifdef __GNU__
> > +#include <limits.h>
> > +#endif

> Why are you including limits.h, it does not seem to be needed.

Yes you are right, it does not seem to be needed. Don't remember why I
included it.

> So, while doing realpath() would seem to be the correct thing to do
> everywhere, as the initial symlink might point to another symlink,
> this changes behaviour only for Hurd, which I think it's a bad idea.
> But using realpath(foo, NULL) is not really portable and would need to
> be checked at build time if it was to be used everywhere.

OK! The reason for my proposed changes was to make only Hurd-specific
changes, since people seem to be very anxious about changes touching
other architectures. But if you say we could do that, no problem.

> So what about the attached patch instead (which I had around from some
> time ago when I took a look at this, although forgot it in my kvm :/,
> beware only build tested).

Your patch seems to be a better solution than mine. It will be up to the
DM to decide then.

> It also changes the kFreeBSD patch because usually __GLIBC__ is not
> predefined and it seems confusing to have it in there. (Ideally the
> build system would switch to detect features at build time, instead of
> hard-coding system support.)

Yes, this would be a very good goal indeed. Has build-time feature
detection been implemented somewhere?




Reply to: