lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YWBvoFW1RDQDYAGx@renaissance-vector>
Date:   Fri, 8 Oct 2021 18:19:44 +0200
From:   Andrea Claudi <aclaudi@...hat.com>
To:     Phil Sutter <phil@....cc>, netdev@...r.kernel.org,
        stephen@...workplumber.org, dsahern@...il.com, bluca@...ian.org,
        haliu@...hat.com
Subject: Re: [PATCH iproute2 v4 0/5] configure: add support for libdir and
 prefix option

On Fri, Oct 08, 2021 at 03:50:25PM +0200, Phil Sutter wrote:

[...]

> > This avoid the endless loop and allows configure to terminate correctly,
> > but results in an error anyway:
> > 
> > $ ./configure --include_dir
> > ./configure: line 544: shift: shift count out of range
> 
> Ah, I didn't see it with bash. I don't think it's a problem though:
> Input is invalid, the loop is avoided and (depending on your patches)
> there will be another error message complaining about invalid $INCLUDE
> value.
> 

Yes, this error can be disregarded. Still I would try to avoid a
meaningless error message, if possible.

[...]

> 
> Which sounds like you'll start accepting things like
> 
> | ./configure --include_dir foo bar
> 

We already accept things like this in the current configure, and I would
try to not modify current behaviour as much as possible.

[...]

> > > Can't you just:
> > > 
> > > | [ -n "$PREFIX" ] && echo "PREFIX=\"$PREFIX\"" >>config.mk
> > > | [ -n "$LIBDIR" ] && echo "LIBDIR=\"$LIBDIR\"" >>config.mk
> > > 
> > > and leave the default ("?=") cases in Makefile in place?
> > > 
> > > Either way, calling 'eval' seems needless. I would avoid it at all
> > > costs, "eval is evil". ;)
> > 
> > Unfortunately this is needed because some packaging systems uses
> > ${prefix} as an argument to --libdir, expecting this to be replaced with
> > the value of --prefix. See Luca's review to v1 for an example [1].
> > 
> > I can always avoid the eval trying to parse "${prefix}" and replacing it
> > with the PREFIX value, but in this case "eval" seems a bit more
> > practical to me... WDYT?
> 
> Do autotools support that? If not, I wouldn't bother.

I don't know about autotools, but Debian packaging system makes use of
this, and we cannot break their workflow.

Regards,
Andrea

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ