Re: Netsurf build failure: 'PATH_MAX' undeclared
Jeffrey Walton, le lun. 26 avril 2021 15:25:23 -0400, a ecrit:
> On Mon, Apr 26, 2021 at 3:12 PM Samuel Thibault <sthibault@debian.org> wrote:
> >
> > Jeffrey Walton, le lun. 26 avril 2021 15:08:28 -0400, a ecrit:
> > > On Mon, Apr 26, 2021 at 2:58 PM Samuel Thibault <sthibault@debian.org> wrote:
> > > >
> > > > Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
> > > > > On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado <phlogiston@sapo.pt> wrote:
> > > > > >
> > > > > > On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
> > > > > > > João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
> > > > > > > > > src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
> > > > > > > >
> > > > > > > > https://buildd.debian.org/status/package.php?p=netsurf
> > > > > > > >
> > > > > > > > Is this something easy to fix and patch?
> > > > > > >
> > > > > > > Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
> > > > > > >
> > > > > > > > would there be other packages in the repository affected by the same
> > > > > > > > problem?
> > > > > > >
> > > > > > > Various packages wrongly think that mach == apple. The fix is usually
> > > > > > > very simple.
> > > > > >
> > > > > > Thank you Samuel for the useful pointers.
> > > > > >
> > > > > > I made some simple changes to the time.c file and the build went on, only to
> > > > > > fail at some later stage. The error that I'm getting is:
> > > > > >
> > > > > > frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url':
> > > > > > frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
> > > > > > function)
> > > > > > 252 | char buf[PATH_MAX];
> > > > > >
> > > > > > Now, the only C I know is what I can guess from other programming languages I'm
> > > > > > familiar with, but this seems simple and not very hurd specific. However the
> > > > > > build does not seem to have any problems on other platforms, so I don't know.
> > > > > > Anyone has an idea on how to best approach this?
> > > > >
> > > > > Ensure you are including <limits.h> in the source file. That's usually
> > > > > the place PATH_MAX is defined.
> > > >
> > > > Please always read the porting guideline page, it discusses such things.
> > > >
> > > > > You can search for symbols on the Posix website at https://pubs.opengroup.org:
> > > > >
> > > > > https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
> > > >
> > > > Yes, but PATH_MAX is not mandatory, and it is indeed not defined on
> > >
> > > > GNU/Hurd. Please read the mentioned page.
> > >
> > > Instead of asking the world to do something special, perhaps Hurd
> > > should do what people expect?
> >
> > People should *not* expect PATH_MAX to be defined.
> >
> > Using PATH_MAX is most often a sign of laziness, that possibly entails
> > bugs or even security holes.
>
> Or expediency. Nearly all operating systems provide PATH_MAX.
Yes, 'Nearly'. Also nearly all operating systems are monolithical. And
nearly all operating systems are Windows.
> > > Doing what the world expects is economical.
> >
> > Yes. And we should also burn all the petrol we have on earth since it's
> > economical.
>
> https://www.google.com/search?q=logical+fallacy+faulty+analogy
Also, lack of being able to extrapolate what the other wants to say.
It's not because something is economical that one should want to do it.
You don't even seem to realize that defining PATH_MAX *does* pose
problem, notably with the actual semantic of realpath(), due to the
semantic that posix attaches to it.
Samuel
Reply to: