On Tue, 2017-12-26 at 19:44 -0800, Yuri wrote:
> On 12/26/17 19:38, Paul Smith wrote:
> > If the BSD Ports framework is setting some variables "as if" they
> > were provided on the command line,
>
> But there is no such thing as "providing something as if on the
> command line".
You're clearly in
On 12/26/17 19:38, Paul Smith wrote:
If the BSD Ports framework is setting
some variables "as if" they were provided on the command line,
But there is no such thing as "providing something as if on the command
line".
It is either on the command line, or not. In this case, the ARCH
variable
On Tue, 2017-12-26 at 14:12 -0800, Yuri wrote:
> pstree shows that this is the only instance of gmake in the system. The
> parent process is BSD make called by framework.
So maybe ARCH is set by BSD make on (one of) its command line(s), then
inherited by GNU make.
> So I am confident that
>
> 1
On 12/26/17 13:59, Paul Smith wrote:
You need to find the parent PID of that gmake command and see who calls
it, and investigate that.
pstree shows that this is the only instance of gmake in the system. The
parent process is BSD make called by framework.
So I am confident that
1. ARCH isn
On Tue, 2017-12-26 at 13:38 -0800, Yuri wrote:
> On 12/26/17 13:29, Paul Smith wrote:
> > Well, this clearly shows that the ARCH variable has been supplied
> > on the command line, NOT through the environment.
>
> Except, it was not!
It was... somehow.
> When I stop the make process, and look at
On 12/26/17 13:29, Paul Smith wrote:
Well, this clearly shows that the ARCH variable has been supplied on
the command line, NOT through the environment.
Except, it was not!
When I stop the make process, and look at its info under /proc, ARCH is
certainly not in the supplied arguments:
$
On Tue, 2017-12-26 at 13:07 -0800, Yuri wrote:
> On 12/26/17 12:47, Paul Smith wrote:
> > Again, the "-p" option will tell you if that is so.
>
>
> With -p, ARCH appears in these lines:
>
> # automatic
> -*-command-variables-*- := SHARED=true LDFLAGS=-fstack-protector\
> -L/usr/local/lib\ -lgmp
On 12/26/17 12:47, Paul Smith wrote:
Again, the "-p" option will tell you if that is so.
With -p, ARCH appears in these lines:
# automatic
-*-command-variables-*- := SHARED=true LDFLAGS=-fstack-protector\
-L/usr/local/lib\ -lgmp\ -lm\ -lz DCC=cc LINKCC=cc CC=cc _SMP_CPUS=8
_PKG_CHECKED=1 _P
On Tue, 2017-12-26 at 12:29 -0800, Yuri wrote:
> On 12/26/17 11:37, Paul Smith wrote:
> > to the makefile right after you assign ARCH and see whether the
> > shell result is what you expect, and whether the ARCH assignment
> > here is what you expect.
> >
> > Also, if you invoke make with the '-p'
On 12/26/17 11:37, Paul Smith wrote:
to the makefile right after you assign ARCH and see whether the shell
result is what you expect, and whether the ARCH assignment here is what
you expect.
Also, if you invoke make with the '-p' option it will show you where
all the variables are assigned alon
On Tue, 2017-12-26 at 09:59 -0800, Yuri wrote:
> Here are all lines where the variable ARCH appears in the makefile. ARCH
> doesn't get substituted. Renaming ARCH -> ARCHX changes the behavior to
> what is expected.
>
> ARCH:= $(shell uname -m | ...)
> OSTYPE := $(shell uname -s | ...)
> B
On 12/26/17 07:26, Paul Smith wrote:
A faster way for you to get answers would be to put the relevant
makefile lines into your email so we could all see them without
installing an entirely different operating system, or pulling down a
software package, unpacking it, and snuffling through its buil
On Mon, 2017-12-25 at 16:09 -0800, Yuri wrote:
> The easiest way to reproduce:
>
> 1. Have FreeBSD installed with the current version of ports
I'm not sure about others but I don't have FreeBSD installed, and I
don't particularly want to spend my holidays installing it.
A faster way for you to g
13 matches
Mail list logo
