Re: The ports collection has some serious issues

[Shane Ambler]

On 12/12/2016 13:12, Janky Jay, III wrote:

Hello scratch,

On 12/11/2016 03:35 PM, scratch65...@att.net wrote:

I have to admit that I avoid ports if at all possible because
I've hardly ever been able to do a build that ran to completion.
There's always some piece of code that's missing and can't be
found, or is the wrong version, et lengthy cetera.   I've never
done release engineering, but I honestly can't imagine how some
of the stuff that makes its way into the ports tree ever got past
QA.  It would get someone sacked if it happened in industry.

If the dev schedule would SLOW DOWN and the commitment switched
to quality from the current emphasis on frequency, with separate
trees for alpha-, beta-, and real release-quality, fully-vetted
code, the ports system might become usable again.


Note that there are over 26000 ports, over 1600 port maintainers and
hundreds of third party projects get updated every day. While the port
maintainers spend a good portion of their spare time trying to keep it
building there will be times that some ports fail to build.

The HEAD of the ports svn repo is for the cutting edge development, a
quarterly branch is created every three months and is only updated to
receive security and build or runtime fixes during that time.

The quarterly ports has been setup for a couple of years but doesn't
seem to be documented well, or it just isn't obvious to find. You can
use svn to checkout a stable branch by specifying a branch name, such as
ports/branches/2016Q4 instead of ports/head. You can also adjust pkg to
use the quarterly ports by changing the pkg repo URL from
pkg.FreeBSD.org/${ABI}/latest to pkg.FreeBSD.org/${ABI}/quarterly


This very, VERY rarely happens to me and I use ports *ONLY* in
production environments. If you could please provide examples and report
the issues to the port maintainer of the ports with issues, that would
greatly help this situation. (Please don't take this as an insult or
anything other than trying to be helpful...) Simply complaining about it
without providing any additional information is certainly not going to
improve anything.


I would say this rarely happens with the default setup, the more port
options you change the more likely it is something will break.


--
FreeBSD - the place to B...Software Developing

Shane Ambler

___
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: The ports collection has some serious issues

[Grzegorz Junka]

On 12/12/2016 02:42, Janky Jay, III wrote:

Hello scratch,

On 12/11/2016 03:35 PM, scratch65...@att.net wrote:

I have to admit that I avoid ports if at all possible because
I've hardly ever been able to do a build that ran to completion.
There's always some piece of code that's missing and can't be
found, or is the wrong version, et lengthy cetera.   I've never
done release engineering, but I honestly can't imagine how some
of the stuff that makes its way into the ports tree ever got past
QA.  It would get someone sacked if it happened in industry.

If the dev schedule would SLOW DOWN and the commitment switched
to quality from the current emphasis on frequency, with separate
trees for alpha-, beta-, and real release-quality, fully-vetted
code, the ports system might become usable again.

This very, VERY rarely happens to me and I use ports *ONLY* in
production environments. If you could please provide examples and report
the issues to the port maintainer of the ports with issues, that would
greatly help this situation. (Please don't take this as an insult or
anything other than trying to be helpful...) Simply complaining about it
without providing any additional information is certainly not going to
improve anything.

Being a port maintainer myself, I depend on people reporting any issues
they run into in order to provide the most robust and dependable port I
can. If people never reported any issues and I had no idea there was an
issue with my port, how would I fix it? So, please, PLEASE report any
issues with ports that aren't building. It's not too time consuming on
your part. Just a simple BUG report and how to re-produce and you're
finished.

Kind Regards,
Janky Jay, III




I second scratch. Building the ports with default options may not be an 
issue but I am rarely (if ever) able to build all 1000+ selected ports 
(using poudriere) with the options that I selected. Whenever I can I am 
raising issues with port maintainer but they very rarely get addressed, 
at least in timely fashion. Even with just 1000+ ports, if an issue 
takes a few weeks to resolve (which would be great) it's highly probably 
that at least one other port gets broken by the time the first issue is 
resolved. With that approach I would never be able to cleanly build all 
the ports that I need. So, to make at least some of the build 
successful, I have to revisit various options and try to disable them to 
verify which ones will allow me to build the ports successfully.


It's not as much a compliant, as I understand it's all done by 
volunteers in their free time, but it makes me wonder how FreeBSD even 
gets its current popularity within the industry with such stability.


Grzegorz

___
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: The ports collection has some serious issues

[Janky Jay, III]

Hi Vlad,

On 12/11/2016 07:58 PM, Vlad K. wrote:
> On 2016-12-12 03:42, Janky Jay, III wrote:
>> This very, VERY rarely happens to me and I use ports *ONLY* in
>> production environments. If you could please provide examples and report
>> the issues to the port maintainer of the ports with issues, that would
>> greatly help this situation. (Please don't take this as an insult or
> 
> Good advice, but please rather file a bug report on our bugzilla:
> 
> https://bugs.freebsd.org/bugzilla/enter_bug.cgi?component=Individual%20Port%28s%29=Ports%20%26%20Packages
> 
> 
> Problems reported to maintainers directly cannot be tracked or confirmed
> by other users.
> 

Thanks for the clarification. In my previous response, my
recommendation was to report to both the port maintainer as well as file
a BUG report. I should have been more clear.

Regards,
Janky Jay, III




signature.asc
Description: OpenPGP digital signature

Re: The ports collection has some serious issues

[Janky Jay, III]

Hello scratch,

On 12/11/2016 03:35 PM, scratch65...@att.net wrote:
> I have to admit that I avoid ports if at all possible because
> I've hardly ever been able to do a build that ran to completion. 
> There's always some piece of code that's missing and can't be
> found, or is the wrong version, et lengthy cetera.   I've never
> done release engineering, but I honestly can't imagine how some
> of the stuff that makes its way into the ports tree ever got past
> QA.  It would get someone sacked if it happened in industry.
> 
> If the dev schedule would SLOW DOWN and the commitment switched
> to quality from the current emphasis on frequency, with separate
> trees for alpha-, beta-, and real release-quality, fully-vetted
> code, the ports system might become usable again.

This very, VERY rarely happens to me and I use ports *ONLY* in
production environments. If you could please provide examples and report
the issues to the port maintainer of the ports with issues, that would
greatly help this situation. (Please don't take this as an insult or
anything other than trying to be helpful...) Simply complaining about it
without providing any additional information is certainly not going to
improve anything.

Being a port maintainer myself, I depend on people reporting any issues
they run into in order to provide the most robust and dependable port I
can. If people never reported any issues and I had no idea there was an
issue with my port, how would I fix it? So, please, PLEASE report any
issues with ports that aren't building. It's not too time consuming on
your part. Just a simple BUG report and how to re-produce and you're
finished.

Kind Regards,
Janky Jay, III




signature.asc
Description: OpenPGP digital signature

Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

[Mark Millard]

On 2016-Dec-11, at 3:11 PM, Mark Linimon  wrote:

> On Sun, Dec 11, 2016 at 02:59:36PM -0800, Mark Millard wrote:
>> I tend to have powerpc64 and powerpc patches because of my
>> experimenting with clang targeting them and that the standard
>> powerpc64 build does not boot PowerMac G5's reliably.
> 
> Is that on 10, 11 or -current?

Note: My powerpc64 and powerpc experiments have been targeted
to exploring having/using a modern context on these processors.
I only use gcc 4.2.1 for the TARGET_ARCH=powerpc kernel. I've
used more modern gcc's and/or clang for the buildworld's and
the powerpc64 buildkernel .

I've seen the problem on all 3 and I've used the patch on all 3.
Note that the TARGET_ARCH=powerpc builds had no problem booting
the G5's, only TARGET_ARCH=powerpc64 did. So I only patched
powerpc64. (I've no evidence that the patch would be appropriate
on non-PowerMac powerpc64 contexts: these comments are limited
in scope.)

I no longer actively use 10. I was using 11 once I started
testing use of clang 3.8.0 for targeting powerpc64 and
powerpc --until I switched to testing clang 3.9.0 and so
switched to 12.

I'm told that the amount of ram changes how likely the PowerMac
G5 boot failures are for TARGET_ARCH=powerpc64. My experience with
8GByte, 12 GByte, and 16 GByte would suggest that this is true:
less often on 8GByte than on 16 GByte, for example. The same for
12 vs. 16 --and these two are both so-called "Quad Core" G5s. But
I've seen the problem in all 3 contexts for 10, 11, and 12 absent
my patch (or variations of it).

Nathan Whitehorn recently came up with the explanation of why my
patch helped. I'll not go into all the details unless you care.
The summary is that FreeBSD's kernel was handling something during
Openfirmware being in use but a special register involved did not
have the value that FreeBSD required: it had the old Openfirmware
value restored to it instead. The patch avoids that restore so
that the FreeBSD value is in place.

Nathan has made a stab at removing the live Openfirmware use that
is involved in the problem but as of yet I've not been able to
boot what he last had me try for this.

> On 10 I remember being able to boot reliably but would get random crashes
> every few days.  That machine has been offline for months, however.

I had frequent times of trying a dozen times or more (power-on,
power-off, power-on, . . .) to boot various 10.x's on the 16
GByte G5 Quad Core that I mostly used. I figured out the patch
during 10's time frame as far as my use goes. I've only tried
without the patch a little for later 10.x's, 11, and 12.

Once booted odd crashes were comparatively rare so solid
judgements about that are problematical for my context as
far as observed crashes go: I had no evidence to attribute
the cause with and a low frequency.

The patched code is also used after booting and so should avoid
the specific issue later as well. That does not imply that there
could not be other problems: FreeBSD and OpenFirmware are likely
still not fully matched, just less likely to crash.

I've no such odd after-boot-complete crashes under 11 that I
remember --nor with the patch under 10.x . 12 has suddenly
shutdown without even a console message once. I build it to
go to the ddb> prompt --which it also did not do.

I will note that at least one other person has made variations
of my patch because they had similar problems booting. (I
encouraged some testing of disabling more than I'd disabled.)
Other folks have reported having the boot problems but as far
as I know have not tried some variant of my patch.

(I made the smallest change that I could that changed the
behavior: I removed just one instruction for the specific
special register.)

> mcl

===
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: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

[Mark Linimon]

On Sun, Dec 11, 2016 at 02:59:36PM -0800, Mark Millard wrote:
> I tend to have powerpc64 and powerpc patches because of my
> experimenting with clang targeting them and that the standard
> powerpc64 build does not boot PowerMac G5's reliably.

Is that on 10, 11 or -current?

On 10 I remember being able to boot reliably but would get random crashes
every few days.  That machine has been offline for months, however.

mcl
___
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: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

[Mark Millard]

[After "BUILD_DEPENDS+= gcc6:lang/gcc6" below shows that
portmaster does not do what you indicate the build environment
should do. The beginning is not essential material.]

On 2016-Dec-11, at 4:40 AM, Gerald Pfeifer  wrote:

> On Sun, 11 Dec 2016, Mark Millard wrote:
>> I reported already that devel/kBuild/Makefile has in its
>> Makefile:
>> 
>> USE_GCC=  any
>> 
>> and devel/kBuild is what causes the lang/gcc* build. (I
>> reported more than that but it is the part relevant here.)
> 
> I had read that, and I di investigate.

It was just setup material (context) for what followed. I
had no doubt that you had looked into what I'd reported.

> USE_GCC=any is the equivalent of USE_GCC=4.2+, and lang/gcc6 and
> lang/gcc6-devel should both meet this requirement.
> 
> (In general, do not use a gcc*-devel port unless you really want 
> or need to, though; use the corresponding gcc* port instead.)

In genreal I have avoided *-devel's but with with -r428312 having
updated the likes of devel/powerpc64-gcc and devel/amd64-gcc and
such to be 6.2.0 based I was exploring what combinations of 6.2.0
installations were compatible vs. not.

Historically on, e.g., powerpc64, devel/powerpc64-gcc and the
matching lang/gcc* by version conflicted so I picked an alternate
lang/gcc* if a devel/powerpc64-gcc updated to match what I already
had from lang/gcc* .

>> Additional information (gained later) is that if I "pkg delete 
>> gcc6-devel" then instead of devel/kBuild trying to install lang/gcc6 
>> it tries to install lang/gcc (no number).
> 
> That works as designed.  USE_GCC=yes defaults to lang/gcc.  USE_GCC=any 
> tries to use an existing GCC system compiler and lang/gcc by default if 
> none is present.

Understood.

>> If I clean that out and put back lang/gcc6-devel and try again it 
>> goes back to trying to install lang/gcc6 .
> 
> That is a little odd.  It means gcc6 from lang/gcc6-devel is found
> and identified as a suitable version of GCC.

Yep: odd.

> Then Mk/bsd.gcc.mk adds
> 
>  BUILD_DEPENDS+= gcc6:lang/gcc6
> 
> when it resolves USE_GCC=any.
> 
> That should not trigger and pull in lang/gcc6, though, as long
> as gcc6 is found.

You are wrong relative to portmaster: it uses (from "sh -x"
output, including for its relevant recursive uses):

#  pkg query %n-%v lang/gcc6

as its test and ends up with am empty response that it
interprets as needs-installation. By contrast:

#  pkg query %n-%v lang/gcc6-devel
gcc6-devel-6.2.1.s20161201

gives a match and would be classified as installed.

The sh -x output that is relevant:

+ pm_cd /usr/ports/lang/gcc6
+ builtin cd /usr/ports/lang/gcc6
+ grep -ql ^CONFLICTS Makefile
+ origin=lang/gcc6
+ iport_from_origin lang/gcc6
+ local sn dir
+ [ -n yes ]
+ pkg query %n-%v lang/gcc6
+ return 1
+ iport=''
+ check_exclude lang/gcc6
+ [ -n '' ]
+ return 0
+ [ -n '' -a -n '' ]
+ [ -n '' -a -n '' ]
+ [ -n '' ]
+ check_interactive lang/gcc6
+ [ -n '' ]
+ return 0
+ update_port lang/gcc6
+ local deps
+ [ -n '' ]
+ [ -z '' ]
+ echo '===>>> Launching child to install lang/gcc6'
===>>> Launching child to install lang/gcc6
+ dep_of_deps=2
+ [ -n pm_first_pass ]
+ [ ! '(' -n '' -a -n '' ')' ]
+ num_of_deps=2
+ deps='(2/2)'
+ term_printf ' >> devel/kBuild >> lang/gcc6 (2/2)'
+ echo -e '\n===>>> emulators/virtualbox-ose-additions >> devel/kBuild >> 
lang/gcc6 (2/2)'

===>>> emulators/virtualbox-ose-additions >> devel/kBuild >> lang/gcc6 (2/2)
+ [ -n '' ]
+ printf '\033]0;portmaster: emulators/virtualbox-ose-additions >> devel/kBuild 
>> lang/gcc6 (2/2)\007'
ESC]0;portmaster: emulators/virtualbox-ose-additions >> devel/kBuild >> 
lang/gcc6 (2/2)^G+ [ -n doing_dep_check -o '(' -n '' -a -n pm_first_pass ')' ]
+ unset NO_DEP_UPDATES
+ [ -z '' -o -n pm_first_pass ]
+ sh -x /usr/local/sbin/portmaster -D -K lang/gcc6
+ trap trap_exit INT


>> It appears to be picking up that a gcc is installed when
>> lang/gcc6-devel and that it is is version 6 based but then
>> it looks for lang/gcc6 specifically but does not find it
>> and so tries to install lang/gcc6. Its identification of the
>> version is not enough to identify what specific gcc port
>> to look for but it only looks for the one possible source
>> to satisfy the dependency --and not finding that specific
>> port it then tries to install that specific port that it
>> did not find.
> 
> That's pretty close.  It finds the gcc6 binary and hence settles
> on GCC 6 as the compiler to use, but when resolving dependencies
> then it apparently does not find the gcc6 binary (or does, and
> something triggers a full rebuild regardless with lang/gcc6 instead 
> of the original lang/gcc6-devel).

See above for what portmaster really does.

> Do you, by any chance, have some non-standard settings that would
> trigger such an unconditional rebuild?

I try to be as standard as I can given that I experiment with
clang targeting powerpc64 and powerpc and other such oddities
and that I want rather current C++ language/library standards.
 
> In general, for 

Re: The ports collection has some serious issues

[scratch65535]

I have to admit that I avoid ports if at all possible because
I've hardly ever been able to do a build that ran to completion. 
There's always some piece of code that's missing and can't be
found, or is the wrong version, et lengthy cetera.   I've never
done release engineering, but I honestly can't imagine how some
of the stuff that makes its way into the ports tree ever got past
QA.  It would get someone sacked if it happened in industry.

If the dev schedule would SLOW DOWN and the commitment switched
to quality from the current emphasis on frequency, with separate
trees for alpha-, beta-, and real release-quality, fully-vetted
code, the ports system might become usable again.
___
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: Help with C++, gcc4.9 and libstdc++

[Fernando Apesteguía]

On Tue, Nov 29, 2016 at 9:28 PM, Fernando Apesteguía
 wrote:
> El 29 nov. 2016 18:58, "Rainer Hurling"  escribió:
>>
>> Hi Fernando,
>>
>> Am 29.11.2016 um 17:50 schrieb Fernando Apesteguía:
>> > I maintain a port written mostly in C++ (cad/openvsp).
>> >
>> > This port used to compile fine in 11 and 10.x in both i386 and amd64.
>> > Since Nov 22nd I'm receiving a pkg-fallout for this port in 10.1. The
>> > port fails with this message:
>> >
>> > undefined reference to `__cxa_throw_bad_array_new_length'
>> >
>> > I assume the source of the problem is defaulting to gcc 4.9 in the
>> > ports and it seems to be related to libstdc++
>> >
>> > I use USES=compiler:gcc-c++11-lib in the Makefile since some c++11
>> > features are required. Any idea of why this could be failing to link?.
>> > What puzzles me is that it compiles fine with gcc 4.9 in 10.2.
>> >
>> > Thanks in advance.

Until that time comes, I would like to send an update but I'm having
some problems with it. I need a c++11 lib but I need gcc < 4.9 for the
port to compile on 10.1 (in < 10.x it doesn't build due to the lack of
certain math functions and in > 10.2 it compiles nicely). I've been
playing around with USE_GCC = 4.8 to no luck.

How can I specify both, gcc 4.8 specifically and still getting all the
work behing the gcc-c++11-lib ARG?

Thanks in advance.

>>
>> this also happens with a few other ports, and is described in
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214863
>>
>> As far, as I understand, a patch with a workaround will be committed in
>> the next time.
>
> Thanks for the info!
>
>>
>> HTH,
>> Rainer
___
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: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

[Gerald Pfeifer]

On Sun, 11 Dec 2016, Mark Millard wrote:
> I reported already that devel/kBuild/Makefile has in its
> Makefile:
> 
> USE_GCC=  any
> 
> and devel/kBuild is what causes the lang/gcc* build. (I
> reported more than that but it is the part relevant here.)

I had read that, and I di investigate.

USE_GCC=any is the equivalent of USE_GCC=4.2+, and lang/gcc6 and
lang/gcc6-devel should both meet this requirement.

(In general, do not use a gcc*-devel port unless you really want 
or need to, though; use the corresponding gcc* port instead.)

> Additional information (gained later) is that if I "pkg delete 
> gcc6-devel" then instead of devel/kBuild trying to install lang/gcc6 
> it tries to install lang/gcc (no number).

That works as designed.  USE_GCC=yes defaults to lang/gcc.  USE_GCC=any 
tries to use an existing GCC system compiler and lang/gcc by default if 
none is present.

> If I clean that out and put back lang/gcc6-devel and try again it 
> goes back to trying to install lang/gcc6 .

That is a little odd.  It means gcc6 from lang/gcc6-devel is found
and identified as a suitable version of GCC.

Then Mk/bsd.gcc.mk adds

  BUILD_DEPENDS+= gcc6:lang/gcc6

when it resolves USE_GCC=any.

That should not trigger and pull in lang/gcc6, though, as long
as gcc6 is found.

> It appears to be picking up that a gcc is installed when
> lang/gcc6-devel and that it is is version 6 based but then
> it looks for lang/gcc6 specifically but does not find it
> and so tries to install lang/gcc6. Its identification of the
> version is not enough to identify what specific gcc port
> to look for but it only looks for the one possible source
> to satisfy the dependency --and not finding that specific
> port it then tries to install that specific port that it
> did not find.

That's pretty close.  It finds the gcc6 binary and hence settles
on GCC 6 as the compiler to use, but when resolving dependencies
then it apparently does not find the gcc6 binary (or does, and
something triggers a full rebuild regardless with lang/gcc6 instead 
of the original lang/gcc6-devel).


Do you, by any chance, have some non-standard settings that would
trigger such an unconditional rebuild?


In general, for ports work lang/gcc is the one to use, and lang/gccX 
over lang/gccX-devel.

Somehow it feels your setup adds layers of shaky, untested and
non-standard elements on top of each other.


As far as lang/gcc* ports are concerned, I believe the best use
of our time will be moving lang/gcc from GCC 4.9 (where it finally
got to) to GCC 5.

Gerald
___
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: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

[Mark Millard]

On 2016-Dec-11, at 1:39 AM, Gerald Pfeifer  wrote:

> Hi Mark,
> 
> On Sat, 10 Dec 2016, Mark Millard wrote:
>> [Top post of example lack of lang/gcc6-devel vs. lan/gcc6
>> substitutability. Context /usr/ports/ at -r428325 (other
>> than a few specially controlled items.]
> 
> I had another look, and lang/gcc6 and lang/gcc6-devel really are
> substitutable in what they provide.
> 
>> After installing lang/gcc6-devel something else indirectly
>> forced lang/gcc6 to try to build. The attempt failed with:
> 
> That means that "something else indirectly forc[ing] lang/gcc6" is
> what appears to be going on here.  I double checked Mk/bsd.gcc.mk
> and failed to find anything (which also would be surprising given
> no other reports in the last decade).
> 
> vbox@, any ideas?
> 
> Gerald

Hi Gerald,

I reported already that devel/kBuild/Makefile has in its
Makefile:

USE_GCC=  any

and devel/kBuild is what causes the lang/gcc* build. (I
reported more than that but it is the part relevant here.)

Additional information (gained later) is that if I "pkg
delete gcc6-devel" then instead of devel/kBuild trying
to install lang/gcc6 it tries to install lang/gcc (no
number). If I clean that out and put back lang/gcc6-devel
and try again it goes back to trying to install lang/gcc6 .

It appears to be picking up that a gcc is installed when
lang/gcc6-devel and that it is is version 6 based but then
it looks for lang/gcc6 specifically but does not find it
and so tries to install lang/gcc6. Its identification of the
version is not enough to identify what specific gcc port
to look for but it only looks for the one possible source
to satisfy the dependency --and not finding that specific
port it then tries to install that specific port that it
did not find.

By contrast when no lang/gcc* is present (none installed)
because I've also deleted lang/gcc6-devel it goes for the
default gcc rather than a more specific version: lang/gcc .

This varying behavior might give a clue about what to look
for in the USE_GCC=any mechanism.



Side notes:

On powerpc64 I was able to install both devel/powerpc64-gcc
(with work around for the fact that it is not a true
cross compiler in this context so 6 files do not stage
right) and lang/gcc6 and no conflict was reported.

The mentioned workaround for my context is:

# more ~/powerpc64-gcc_fixup.sh 
#!/bin/sh
cp -ax /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov

cp -ax 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gcov-tool 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool

gzip -c 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/cpp.1 > 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-cpp.1.gz

gzip -c 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/g++.1 > 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-g++.1.gz

gzip -c 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/.build/gcc/doc/gcc.1 > 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-gcc.1.gz

gzip -c 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-*/gcc/doc/gcov.1 > 
/usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/man/man1/powerpc64-unknown-freebsd12.0-gcov.1.gz

after which I use -C with portmaster to let it continue now
that it can find the 6 files when it tries to.



There are other issues in how things are operating and
I'll not look into them until after I've gotten some sleep
(or even later then that).

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


> The specific example turns out to be. . .
> 
> emulators/virtualbox-ose-additions leads to:
> 
> ===>>> The following actions will be taken if you choose to proceed:
>Upgrade virtualbox-ose-additions-5.1.8 to 
> virtualbox-ose-additions-5.1.10
>Install devel/kBuild
>Install lang/gcc6
>Install textproc/flex
> 
> and lang/gcc6 tries to build during devel/kBuild and the 3
> non-lang/gcc6 items above have:
> 
> # grep -i gcc emulators/virtualbox-ose-additions/Makefile 
> devel/kBuild/Makefile textproc/flex/Makefile 
> emulators/virtualbox-ose-additions/Makefile:CONFIGURE_ARGS+=--nofatal 
> --with-gcc="${CC}" --with-g++="${CXX}"
> emulators/virtualbox-ose-additions/Makefile:@${ECHO} 'VBOX_GCC_std = 
> -std=c++11' >> ${WRKSRC}/LocalConfig.kmk
> emulators/virtualbox-ose-additions/Makefile:@${ECHO} 
> 'VBOX_GCC_Wno-unused-parameter = -Wno-unused-parameter' >> \
> devel/kBuild/Makefile:USE_GCC=  any
> devel/kBuild/Makefile:  ${REINPLACE_CMD} -e 's|gcc|${CC}|g' $$f ; \
> 
> In a context with:
> 
> # pkg info | grep -i gcc
> gcc6-devel-6.2.1.s20161201 GNU Compiler 

Re: net/haproxy 1.7.0 : libressl support

[Franco Fichtner]

> On 9 Dec 2016, at 11:51 AM, Dmitry Sivachenko  wrote:
> 
> If they reject it and refuse to support libressl for some reason, we will not 
> add your patches too, because this is not something FreeBSD-specific.

Strongswan developers said similar things.  Unfortunately,
we have very good support of LibreSSL in the FreeBSD ports
tree since 2015.  No reason to flush this down the toilet,
not yet anyway if the patches work.

We used to have this patch, it still fixes strongswan,
likely fixes haproxy 1.7:

https://github.com/opnsense/ports/commit/7e8ea59cabc

I brought this up with LibreSSL developers, some other
users from different BSD projects noted this needs fixing
too.  We're not there yet, but we can find a solution if
everyone does their part in embracing choice for users.  :)


Cheers,
Franco
___
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"