[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_chroot: ChangeLog pam_chroot-0.9.2.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_chroot: ChangeLog pam_chroot-0.9.2.ebuild

[Donnie Berkholz]

On 07:46 Mon 01 Oct     , Ali Polatel (hawking) wrote:
> 1.1                  sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild
> 
> file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild?rev=1.1&view=markup
> plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild?rev=1.1&content-type=text/plain

> 	LDFLAGS="$(raw-ldflags)" emake \
> 		CC="$(tc-getCC)" LD="$(tc-getLD)" || die "emake failed"

This reads really strangely to me. It's passing variables on both sides 
of emake. Generally one would just pick a side (afterwards) and add 
everything there.

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_chroot: ChangeLog pam_chroot-0.9.2.ebuild

[Ali Polatel]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

Mon, Oct 01, 2007 at 01:06:42AM -0700 tarihinde, Donnie Berkholz yazmış:
> On 07:46 Mon 01 Oct     , Ali Polatel (hawking) wrote:
> > 1.1                  sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild
> > 
> > file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild?rev=1.1&view=markup
> > plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild?rev=1.1&content-type=text/plain
> 
> > 	LDFLAGS="$(raw-ldflags)" emake \
> > 		CC="$(tc-getCC)" LD="$(tc-getLD)" || die "emake failed"
> 
> This reads really strangely to me. It's passing variables on both sides 
> of emake. Generally one would just pick a side (afterwards) and add 
> everything there.

Well, here is the related part from Makefile:

LDFLAGS  := -x --shared $(LDFLAGS)

emake LDFLAGS="$(raw-ldflags)" overrides that definition,
emake LDFLAGS="-x --shared $(raw-ldflags)" works as expected, or my
version, maybe I should add a note about it to the ebuild...

> Thanks,
> Donnie

-- 
ali polatel (hawking)

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_chroot: ChangeLog pam_chroot-0.9.2.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Monday 01 October 2007, Donnie Berkholz wrote:
> On 07:46 Mon 01 Oct     , Ali Polatel (hawking) wrote:
> > 1.1                  sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild
> >
> > file :
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_c
> >hroot-0.9.2.ebuild?rev=1.1&view=markup plain:
> > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam_c
> >hroot-0.9.2.ebuild?rev=1.1&content-type=text/plain
> >
> > 	LDFLAGS="$(raw-ldflags)" emake \
> > 		CC="$(tc-getCC)" LD="$(tc-getLD)" || die "emake failed"
>
> This reads really strangely to me. It's passing variables on both sides
> of emake. Generally one would just pick a side (afterwards) and add
> everything there.

while i cant speak for this case, make provides the ability to check for the 
location of where a variable is defined and change behavior based on it ... 
here, make would say LDFLAGS is in the environment while CC and LD were 
defined on the command line ... see the $(origin) function

also, make changes behavior for setting of variables based on the origin of 
definition ... the "=" and "+=" operators get ignored when the variable is on 
the command line, but work when in the environment ... then again, makefiles 
that get screwy based on this i think are broken in the first place and 
should get fixed ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_chroot: ChangeLog pam_chroot-0.9.2.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

On Monday 01 October 2007, Ali Polatel wrote:
> Mon, Oct 01, 2007 at 01:06:42AM -0700 tarihinde, Donnie Berkholz yazmış:
> > On 07:46 Mon 01 Oct     , Ali Polatel (hawking) wrote:
> > > 1.1                  sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild
> > >
> > > file :
> > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam
> > >_chroot-0.9.2.ebuild?rev=1.1&view=markup plain:
> > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam
> > >_chroot-0.9.2.ebuild?rev=1.1&content-type=text/plain
> > >
> > > 	LDFLAGS="$(raw-ldflags)" emake \
> > > 		CC="$(tc-getCC)" LD="$(tc-getLD)" || die "emake failed"
> >
> > This reads really strangely to me. It's passing variables on both sides
> > of emake. Generally one would just pick a side (afterwards) and add
> > everything there.
>
> Well, here is the related part from Makefile:
>
> LDFLAGS  := -x --shared $(LDFLAGS)
>
> emake LDFLAGS="$(raw-ldflags)" overrides that definition,
> emake LDFLAGS="-x --shared $(raw-ldflags)" works as expected, or my
> version, maybe I should add a note about it to the ebuild...

assuming they actually need to prepend here, you could get upstream to write 
it like so:
override LDFLAGS := -x --shared $(LDFLAGS)

if prepending is not needed, then this could work just as well:
override LDFLAGS += -x --shared

not sure how portable "override" is though ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-auth/pam_chroot: ChangeLog pam_chroot-0.9.2.ebuild

[Ali Polatel]

[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]

Mon, Oct 01, 2007 at 04:31:42AM -0400 tarihinde, Mike Frysinger yazmış:
> On Monday 01 October 2007, Ali Polatel wrote:
> > Mon, Oct 01, 2007 at 01:06:42AM -0700 tarihinde, Donnie Berkholz yazmış:
> > > On 07:46 Mon 01 Oct     , Ali Polatel (hawking) wrote:
> > > > 1.1                  sys-auth/pam_chroot/pam_chroot-0.9.2.ebuild
> > > >
> > > > file :
> > > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam
> > > >_chroot-0.9.2.ebuild?rev=1.1&view=markup plain:
> > > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-auth/pam_chroot/pam
> > > >_chroot-0.9.2.ebuild?rev=1.1&content-type=text/plain
> > > >
> > > > 	LDFLAGS="$(raw-ldflags)" emake \
> > > > 		CC="$(tc-getCC)" LD="$(tc-getLD)" || die "emake failed"
> > >
> > > This reads really strangely to me. It's passing variables on both sides
> > > of emake. Generally one would just pick a side (afterwards) and add
> > > everything there.
> >
> > Well, here is the related part from Makefile:
> >
> > LDFLAGS  := -x --shared $(LDFLAGS)
> >
> > emake LDFLAGS="$(raw-ldflags)" overrides that definition,
> > emake LDFLAGS="-x --shared $(raw-ldflags)" works as expected, or my
> > version, maybe I should add a note about it to the ebuild...
> 
> assuming they actually need to prepend here, you could get upstream to write 
> it like so:
> override LDFLAGS := -x --shared $(LDFLAGS)
> 
> if prepending is not needed, then this could work just as well:
> override LDFLAGS += -x --shared
> 
> not sure how portable "override" is though ...

This works, another idea is to put '-x --shared' somewhere else, maybe
to the command line or to another variable. Options that are required to
make the program work fine shouldn't be in variables that can be
overridden imo.
I'll talk to upstream about it.

> -mike

-- 
ali polatel (hawking)

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]