Re: Status of portupgrade and portmaster?

2017-10-01 Thread Matthew D. Fuller
On Fri, Sep 29, 2017 at 09:21:31PM +0200 I heard the voice of
Marco Beishuizen, and lo! it spake thus:
> 
> Using portupgrade every day and still works great. Tried portmaster
> once but liked portupgrade more. I use poudriere just for testing
> ports.

I also use portupgrade constantly on several systems, and portmaster
occasionally for some special cases where it has advantages.

I also use poudriere on a lot of systems.  Actually, most, nowadays.
And I'm extremely happy with it.  But I expect the systems I'm running
straight out of ports now will continue to do so for a very long time,
since poudriere just won't fit at all.


-- 
Matthew Fuller (MF4839)   |  fulle...@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
   On the Internet, nobody can hear you scream.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Status of portupgrade and portmaster?

2017-10-01 Thread Vlad K.

On 2017-10-02 00:19, RW via freebsd-ports wrote:

I meant installing up-to-date packages from the *local* repository. So
if only Firefox needs to be updated would Poudriere first install
Firefox's dependencies into the jail from locally generated package
files before building Firefox.


Poudriere builds repositories and yes, uses any package already built in 
that repository if it's a build dependency for another. Note that you 
have multiple repos, built with different base jails, different ports 
trees, different sets of packages, options, make.conf options.


But even for single machine use, it allows simple building of any list 
of wanted packages, it makes sure those and their dependencies are 
built, up to date (relative to the ports tree it's configured to use), 
and kept as a persistent repository. You can even delete a package txz 
from the repo manually, on next bulk run it will simply rebuild what's 
missing.



--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Status of portupgrade and portmaster?

2017-10-01 Thread RW via freebsd-ports
On Sun, 01 Oct 2017 20:53:29 +0200
Vlad K. wrote:

> On 2017-10-01 18:24, RW via freebsd-ports wrote:
> > 
> > Do you mean as opposed to installing the dependencies from the
> > repository, or are you saying that it rebuilds them?  
> 
> Poudriere builds isolated, in jails. That means it's not reusing 
> packages installed on the host, nor from another repo, if those are 
> needed as (build) dependencies.

I meant installing up-to-date packages from the *local* repository. So
if only Firefox needs to be updated would Poudriere first install
Firefox's dependencies into the jail from locally generated package
files before building Firefox.

If that happens then there wouldn't be much incentive to use anything
from the host as any package installed on the host would be in the
local repository - you'd just save a few installs.

 
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


FreeBSD Port: sudo-1.8.21p2 - 1.8.21p2 SegFaults

2017-10-01 Thread David P. Discher
Hi Renato & ports :

I was just stumble over this, with 12.0-CURRENT r323934, sudo 1.8.21p2 
SegFaults when run in a bhyve VM - however, seemly on bare metal, its fine.

sudo-1.8.20p2_3 runs just fine in bhyve VM.  There are all my own builds of 12- 
and ports (via poudriere).  I recompiled sudo on the Bhyve, and still had the 
same issue.


--
David P. Discher • d...@ixsystems.com
Director, Information Technology
iXsystems, Inc.
Office: 408.943.4100 x150
Mobile: 408.368.3725




signature.asc
Description: Message signed with OpenPGP


Re: Status of portupgrade and portmaster?

2017-10-01 Thread Vlad K.

On 2017-10-01 18:24, RW via freebsd-ports wrote:


Do you mean as opposed to installing the dependencies from the
repository, or are you saying that it rebuilds them?


Poudriere builds isolated, in jails. That means it's not reusing 
packages installed on the host, nor from another repo, if those are 
needed as (build) dependencies.


Unless of course it grew this ability recently and I'm gravely mistaken, 
but I don't know of such addition.




--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Debugging A Port

2017-10-01 Thread Amit Yaron

Thanks,
 It seems to work.

On 01.10.2017 20:42, Kurt Jaeger wrote:

Hi!


What action will make the Make command to recompile a source file?


That depends on the port, there's no generic way to say.

Basically, the port framework adds a wrapper of targets
around the upstream source Makefile and those targets can shield
a recompile from happening.

What sometimes work is this:

cd work//
make



___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


lang/pdflib: I've submitted bugzilla 222722 with a patch for allowing lang/pdflib to build under __POWERPC__

2017-10-01 Thread Mark Millard
I wrote in bugziila 222722:

> [I tried to build math/gnuplot and it was
> indirectly blocked by print/pdflib failing
> to build for "missing" include files.]
> 
> The following avoids print/pdflib classifying the
> context as an old MAC context (pre-MACOSX) when
> building for powerpc64 (for example):
> 
> # more /usr/ports/print/pdflib/files/patch-libs_pdcore_pc__config.h
> --- libs/pdcore/pc_config.h.orig2012-06-06 11:58:58 UTC
> +++ libs/pdcore/pc_config.h
> @@ -179,9 +179,11 @@
>  
>  /* try to identify Mac OS 9 compilers */
>  
> +#if 0
>  #if (defined macintosh || defined __POWERPC__ || defined __CFM68K__) && \
> !defined MAC && !defined MACOSX && !defined __BEOS__
>  #define MAC
> +#endif
>  #endif
>  
>  /*


===
Mark Millard
markmi at dsl-only.net

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Debugging A Port

2017-10-01 Thread Kurt Jaeger
Hi!

> What action will make the Make command to recompile a source file?

That depends on the port, there's no generic way to say.

Basically, the port framework adds a wrapper of targets
around the upstream source Makefile and those targets can shield
a recompile from happening.

What sometimes work is this:

cd work//
make

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Debugging A Port

2017-10-01 Thread Amit Yaron

Hi,

What action will make the Make command to recompile a source file?

Thanks,
  Amit
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Status of portupgrade and portmaster?

2017-10-01 Thread Torfinn Ingolfsen
On Sun, Oct 1, 2017 at 12:34 PM, Carmel NY  wrote:
> lifting leaving me free to work on more important projects. I suppose I could
> always go back to “portupgrade”; however, I understand that it is not being
> maintained either.

FWIW, portupgrade has received enough maintenance that it continues to
work nicely on at least stable/11 and stable/10.
And I am grateful for that.

HTH
-- 
Regards,
Torfinn Ingolfsen
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-10-01 Thread RW via freebsd-ports
On Sun, 01 Oct 2017 12:26:25 +0200
Vlad K. wrote:

> Another problem is poudriere's inability to reuse already installed 
> packages, if they're a dependency for something being built by it. 
> Personally I'd never use that option, as I want clean, isolated
> rebuilds of everything affected, but I can understand how quick
> building of one or two packages could use already installed deps, if
> people wanted that (and break any promise of integrity facilitated
> with isolated builds).

Do you mean as opposed to installing the dependencies from the
repository, or are you saying that it rebuilds them?   
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Status of portupgrade and portmaster?

2017-10-01 Thread Vlad K.

On 2017-10-01 12:34, Carmel NY wrote:


1. Does it determine out-of-date update packages automatically or does
the user have to determine that what is out-of-date and feed them to 
poudriere

manually and in the proper order?

2. From what I have read, the user is required to install each package
manually. Is that correct?


It's not. Poudriere builds a pkg repo, and automatically rebuilds all 
ports that have changed version (including epoch and portrevision, so 
essentially -- changed version string), including all ports that depend 
on ports that changed (see my previous post about frequent rebuilds), or 
became a new dependency.


So you can have it build updates in the background and when you're done, 
just issue pkg upgrade.


Another benefit of this approach is that you don't get partial updates 
for a program that's in active use. I've seen this cause failure a lot 
of times, eg with perl. The master program is running or being actively 
run (from cron or initiated by user), not yet updated but a dep just 
updated. Crash.




I have a small system. Three PCs plus a number of laptops. Only one 
machine
runs FreeBSD. I don’t have the time to be a slave to this system. It 
appears
that there is a considerable amount of manual configuration to get 
poudriere
up and running, which means there is a significant possibility of 
making

mistakes.


Depends on the definition of "significant". With poudriere you really 
have four steps at minimum to get started:


1. create the builder jail (poudriere jail -c ...)
2. create the ports tree (poudriere ports -c ...) -- create new, or 
point it to use system's /usr/ports

3. create a file that lists ports you want build for that repo
3a. optional step, issue poudriere options ..., to set non-default 
options .

4. configure /etc/pkg.conf to use the repo poudriere is building


After that, the workflow is simple:

1. update ports tree (poudriere ports -u)
2. manage new/changed options (poudriere options ...)
3. run build (poudriere bulk ...)
4. when it's done, pkg upgrade

It's covered in the handbook:

https://www.freebsd.org/doc/handbook/ports-poudriere.html


The above is just a minimum, but poudriere allows you to have many 
builder jails (eg for 64 or 32 bit, for different ABIs, ...), and many 
package option sets, so essentially it can create many repositories that 
differ in supported arch, abi, options used, packages listed, ...



--
Vlad K.
Acheron Media, Croatia
www.acheronmedia.hr
+385 95 536 3850
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-10-01 Thread Carmel NY
On Sun, 1 Oct 2017 10:51:39 +0100, Matthew Seaman stated:

>On 30/09/2017 18:06, Kevin Oberman wrote:
>> John did state that he would continue to support synth. I can't say if he
>> has continued to make contributions. In any case, only poudriere is
>> available for maintaining ports in HEAD and I, for one, feel that it is
>> simply unacceptable as it make FreeBSD unusable for those of us with only
>> "small" systems where the weight poudriere simply can't be justified. (I
>> have no system with other than SATA disk drives and, for my current needs,
>> 1 TB of SATA on my development system and .5TB on my production system is
>> adequate. Both systems are physically constrained in expansion capability,
>> though otherwise easily meet my requirements.  
>
>I don't know what it is about poudriere that elicits this immediate
>reaction that it is some sort of behemoth, trampling through disks by
>the bushel, shouldering aside other processes to seize the best bits of
>RAM and making CPUs cry with incessant demands for more cycles.
>
>It's simply not so.
>
>poudriere is really a very thin layer of shell scripts (and a few other
>bits) over the general ports make system.  All of the really heavy
>lifting is done by the compilers and so forth /that you'ld have to
>invoke anyhow/.
>
>In fact, I'd say that if your system is /at all/ capable of building the
>ports you want, then it is perfectly capable of running poudriere to
>help automate that.
>
>Yes, the pkg builders used by the project are pretty chunky bits of kit.
> That's because they are building some 30,000 ports for about 8
>different combinations of OS and CPU architecture with a cycle time of
>less than two days.
>
>If you're just building a few hundred ports for your own consumption,
>then you don't need anything like that amount of resource.  I manage
>perfectly well with a 6-year old Core2Duo with 8GB RAM and some 500GB
>SSDs which cost me under £500 originally + about £200 for replacement
>drives later on.  Which also runs a bunch of other stuff including my
>mail system.

This is probably OT for this thread; however, at this point I don’t think it
matters much.

I have read up on poudriere although I have never used it. I have several
questions that I cannot find the answer too.

1. Does it determine out-of-date update packages automatically or does
the user have to determine that what is out-of-date and feed them to poudriere
manually and in the proper order?

2. From what I have read, the user is required to install each package
manually. Is that correct?

I have a small system. Three PCs plus a number of laptops. Only one machine
runs FreeBSD. I don’t have the time to be a slave to this system. It appears
that there is a considerable amount of manual configuration to get poudriere
up and running, which means there is a significant possibility of making
mistakes.

Synth, and before that “portmanager”, and then “portupgrade” do all the heavy
lifting leaving me free to work on more important projects. I suppose I could
always go back to “portupgrade”; however, I understand that it is not being
maintained either.

If FreeBSD cannot get the problems with synth corrected when FreeBSD-12 is
released, perhaps it will be time to consider a new OS.

-- 
Carmel
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: Status of portupgrade and portmaster?

2017-10-01 Thread Vlad K.

On 2017-10-01 11:51, Matthew Seaman wrote:

poudriere is really a very thin layer of shell scripts (and a few other
bits) over the general ports make system.  All of the really heavy
lifting is done by the compilers and so forth /that you'ld have to
invoke anyhow/.


There is one tiny problem that users see often and that's the rebuilding 
of all reverse deps for any port that changed, which can result with 
frequent rebuilds of tens or hundreds of packages. But -- that's only a 
good thing. I've never had issues with eg. perl upgrades that portmaster 
users seem to have often.


However, CCACHE is very effective in this situation. As an example 
CCACHE reduces building of Firefox from ~45 minutes down to 3-4 minutes, 
in my case.


Another problem is poudriere's inability to reuse already installed 
packages, if they're a dependency for something being built by it. 
Personally I'd never use that option, as I want clean, isolated rebuilds 
of everything affected, but I can understand how quick building of one 
or two packages could use already installed deps, if people wanted that 
(and break any promise of integrity facilitated with isolated builds).


I'll also second the opinion -- if you're building from ports on a 
machine anyway, poudriere does not in any way require any more resources 
except to store produced packages and ccache files, which is not much.



--
Vlad K.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Status of portupgrade and portmaster?

2017-10-01 Thread Thomas Mueller
> John did state that he would continue to support synth. I can't say if he
> has continued to make contributions. In any case, only poudriere is
> available for maintaining ports in HEAD and I, for one, feel that it is
> simply unacceptable as it make FreeBSD unusable for those of us with only
> "small" systems where the weight poudriere simply can't be justified. (I
> have no system with other than SATA disk drives and, for my current needs,
> 1 TB of SATA on my development system and .5TB on my production system is
> adequate. Both systems are physically constrained in expansion capability,
> though otherwise easily meet my requirements.

> As a result, I am no longer able to track HEAD and, if the issue is not
> resolved in some manner before 11 support ends, will be forced to move from
> FreeBSD after an using it for over 2 decades. I certainly hope that this is
> not what happens.

> Kevin Oberman, Part time kid herder and retired Network Engineer

I keep svn-updating 11-STABLE and HEAD, but the ino64 issue with some ports 
including gcc(5,6)-aux holds me back from activity on HEAD.

But conceivably there could be a fix in the future.

I also keep cvs-updating NetBSD-HEAD and pkgsrc.

On FreeBSD, I am also miffed by the lack of support for my Realtek 8111E/8168 
chip on MSI Z77 MPOWER motherboard, especially after that Ethernet worked for a 
time, and still does for Linux (System Rescue CD) and NetBSD.

Synth and pkgng in pkgsrc seem to be falling into desuetude; gcc6-aux is broken 
for NetBSD (stated in the Makefile).

I wonder also about the status of synth and possibly poudriere on DragonFlyBSD, 
idly curious in that I am more favorably impressed by Linux or Haiku, compared 
to DragonFlyBSD.

Tom

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: Status of portupgrade and portmaster?

2017-10-01 Thread Matthew Seaman
On 30/09/2017 18:06, Kevin Oberman wrote:
> John did state that he would continue to support synth. I can't say if he
> has continued to make contributions. In any case, only poudriere is
> available for maintaining ports in HEAD and I, for one, feel that it is
> simply unacceptable as it make FreeBSD unusable for those of us with only
> "small" systems where the weight poudriere simply can't be justified. (I
> have no system with other than SATA disk drives and, for my current needs,
> 1 TB of SATA on my development system and .5TB on my production system is
> adequate. Both systems are physically constrained in expansion capability,
> though otherwise easily meet my requirements.

I don't know what it is about poudriere that elicits this immediate
reaction that it is some sort of behemoth, trampling through disks by
the bushel, shouldering aside other processes to seize the best bits of
RAM and making CPUs cry with incessant demands for more cycles.

It's simply not so.

poudriere is really a very thin layer of shell scripts (and a few other
bits) over the general ports make system.  All of the really heavy
lifting is done by the compilers and so forth /that you'ld have to
invoke anyhow/.

In fact, I'd say that if your system is /at all/ capable of building the
ports you want, then it is perfectly capable of running poudriere to
help automate that.

Yes, the pkg builders used by the project are pretty chunky bits of kit.
 That's because they are building some 30,000 ports for about 8
different combinations of OS and CPU architecture with a cycle time of
less than two days.

If you're just building a few hundred ports for your own consumption,
then you don't need anything like that amount of resource.  I manage
perfectly well with a 6-year old Core2Duo with 8GB RAM and some 500GB
SSDs which cost me under £500 originally + about £200 for replacement
drives later on.  Which also runs a bunch of other stuff including my
mail system.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature


Re: head -r324071 system clang 5 based powerpc64 building ports: lang/gcc7 messed up by a matching name vec_step? [renaming in tree-vect-loop.c avoids the issue]

2017-10-01 Thread Mark Millard
[If work/gcc-7.2.0/gcc/tree-vect-loop.c avoids the
name vec_step then it avoids the conflicting use
for altivec support in the powerpc64 context. I
used vec_step_renamed as the name in
work/gcc-7.2.0/gcc/tree-vect-loop.c instead.
Similarly for devel/powerpc64-gcc and likely
other variants.]

On 2017-Sep-29, at 12:14 PM, Mark Millard  wrote:

> Summary of later additions:
> 
> devel/powerpc64-gcc has the same problem as gcc7
> in this clang-based powerpc64.
> 
> My note about using gcc 4.2.1 for the kernel
> build was wrong. (My 32-bit powerpc builds
> are that way, not the powerpc64 ones.)
> 
> On 2017-Sep-29, at 1:51 AM, Mark Millard  wrote:
> 
>> [Looks like gcc7 might be causing its own problem
>> via a vec_step macro name in its altivec.h .]
>> 
>> On 2017-Sep-29, at 1:14 AM, Mark Millard  wrote:
>> 
>>> I attempted a poudriere based build of some
>>> ports and the gcc7 build involved failed
>>> with the following sorts of notices:
> 
> devel/powerpc64-gcc has the same problem as gcc7
> in this clang-based powerpc64
> 
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:27: 
>>> error: expected unqualified-id
>>> tree new_vec, vec_init, vec_step, t;
>>>^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3835:26: 
>>> error: expected ';' at end of declaration
>>> tree new_vec, vec_init, vec_step, t;
>>>   ^
>>>   ;
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3983:3: 
>>> error: use of undeclared identifier 't'
>>> t = unshare_expr (new_name);
>>> ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3988:49: 
>>> error: use of undeclared identifier 't'
>>> new_vec = build_vector_from_val (stepvectype, t);
>>>  ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:3989:12: 
>>> error: expected expression
>>> vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
>>> ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4011:75: 
>>> error: expected expression
>>> new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, vec_step);
>>>^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4048:7: 
>>> error: use of undeclared identifier 't'
>>>t = unshare_expr (new_name);
>>>^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4051:53: 
>>> error: use of undeclared identifier 't'
>>>new_vec = build_vector_from_val (stepvectype, t);
>>>  ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4052:16: 
>>> error: expected expression
>>>vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
>>> ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:4060:25: 
>>> error: expected expression
>>>vec_def, vec_step);
>>> ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6327:9: 
>>> error: expected unqualified-id
>>>tree vec_step = build_vector_from_val (cr_index_vector_type, step);
>>> ^
>>> /wrkdirs/usr/ports/lang/gcc7/work/gcc-7.2.0/gcc/tree-vect-loop.c:6333:36: 
>>> error: expected expression
>>>create_iv (series_vect, vec_step, NULL_TREE, loop, _gsi,
>>>^
>>> 50 warnings and 12 errors generated.
>>> gmake[3]: *** [Makefile:1099: tree-vect-loop.o] Error 1
>>> gmake[3]: *** Waiting for unfinished jobs
>>> 42 warnings generated.
>>> 51 warnings generated.
>>> 50 warnings generated.
>>> rm gfortran.pod gcc.pod
>>> gmake[3]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build/gcc'
>>> gmake[2]: *** [Makefile:4225: all-gcc] Error 2
>>> gmake[2]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build'
>>> gmake[1]: *** [Makefile:893: all] Error 2
>>> gmake[1]: Leaving directory '/wrkdirs/usr/ports/lang/gcc7/work/.build'
>>> ===> Compilation failed unexpectedly.
>>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
>>> the maintainer.
>>> *** Error code 1
>>> 
>>> Stop.
>>> make: stopped in /usr/ports/lang/gcc7
>>> =>> Cleaning up wrkdir
>>> ===>  Cleaning for gcc7-7.2.0_1
>>> build of lang/gcc7 | gcc7-7.2.0_1 ended at Fri Sep 29 00:22:00 PDT 2017
>>> build time: 00:29:27
>>> !!! build failure encountered !!!
>> 
>> Turns out that there is:
>> 
>> # grep -r "\" ~/poudriere_failure/lang_gcc7/ | more
>> . . .
>> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:/*
>>  Given the vec_step of a type, return the corresponding bool type.  */
>> /root/poudriere_failure/lang_gcc7/work/gcc-7.2.0/gcc/config/rs6000/altivec.h:typename
>>  __altivec_bool_ret ::__ret \
>>