Re: chromium-89.0.4389.114_1 sign-in feature unavailable?

[Dimitry Andric]

On 12 Apr 2021, at 00:24, Jonathan Chen  wrote:
> 
> On Mon, 12 Apr 2021 at 09:51, Dimitry Andric  wrote:
>> 
>> On 11 Apr 2021, at 21:57, Jonathan Chen  wrote:
>>> 
>>> I recently updated to chromium-89.0.4389.114_1, and it now appears
>>> that the browser sync sign-in feature is not available anymore? Or did
>>> I miss something?
>> 
>> Yes, apparently you missed this:
>> 
>> https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html
>> 
>> It was all over the news... :)
> 
> I must not have the right feeds...
> 
> Is the FreeBSD port of chrome considered a "third-party Chromium based
> browser"?

I don't think Google ever officially released a FreeBSD build of the
proprietary Chrome application. They do have official Linux builds, of
course, and it might just be possible to run these under the
Linuxulator, but your mileage may very, as they say.

But yeah, Google has again made a lot of people very unhappy with this
decision. Please draw your own conclusions. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: chromium-89.0.4389.114_1 sign-in feature unavailable?

[Dimitry Andric]

On 11 Apr 2021, at 21:57, Jonathan Chen  wrote:
> 
> 
> I recently updated to chromium-89.0.4389.114_1, and it now appears
> that the browser sync sign-in feature is not available anymore? Or did
> I miss something?

Yes, apparently you missed this:

https://blog.chromium.org/2021/01/limiting-private-api-availability-in.html

It was all over the news... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: TCL and Unicode

[Dimitry Andric]

On 22 Mar 2021, at 14:40, Shawn Webb  wrote:
> 
> I'm tracking down a regression in ports regarding TCL and unicode. The
> primary victim of the problem is databases/sqlite3. Note that I use
> freebsd-ports on github as my upstream, so I'll be using git commit
> hashes from that repo.
> 
> The sqlite3 build failure can be seen at [1].
> 
> If I revert commit 787aad81fc79d441fb0c9a750e6e33b6c0ea7ac6, sqlite3
> builds fine. I noticed a few key changes from that commit:
> 
> The build of sqlite3 depends on TCL: instead of using the distfile
> that has the autoconf artifacts pre-generated, the distfile without
> the autoconf artifacts is used (changing from
> sqlite-autoconf-3340100.tar.gz to sqlite-src-3340100.zip). This
> means that the TCL-based autoconf artifacts must be generated
> locally. At least, partially. It seems that the only part of the
> build that depends on TCL is the sqlite3_analyzer.
> 
> Admittedly, this change is somewhat confusing to me. I'm having
> somewhat of a hard time knowing whether it's TCL or sqlite3 itself
> as the main culprit.
> 
> Any guidance is appreciated.
> 
> [1]: 
> http://ci-08.md.hardenedbsd.org/data/hardenedbsd-current_amd64-local/2021-03-21_13h53m43s/logs/errors/sqlite3-3.34.1,1.log

Hi Shawn,

It builds fine for me locally on 14.0-CURRENT (as of ~2 days ago), and
indeed the sqlite3.c file is now dynamically generated by tcl.

In your CI failure case, it looks like something is inserting blobs of
zero bytes into the resulting file, though? So either the file system
is going bad, or tcl is outputting nonsense, for some reason. At least,
I think you'll have to do some investigations in that direction...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FireFox keeps loosing data

[Dimitry Andric]

On 11 Nov 2020, at 18:31, Andrea Venturoli  wrote:
> 
> Since some months I've been experiencing data loss with Firefox.
> I'm currently running Firefox-esr-78.4.1 on FreeBSD 12.2/amd64.
> 
> I guess this is related to cookies, since it loses saved form data and I keep 
> having to login again on sites where I had logon and never logout, accept 
> privacy statements and tweak cookie settings again and again, etc...
> History is working perfectly, however.
> 
> This is not systematic: i.e. I may login on 
> https://bugs.freebsd.org/bugzilla/, come back tomorrow morning and still be 
> logged in, try again in the afternoon and find I've been logged out.
> I may start FireFox, go to a site, accept cookies, restart FireFox and need 
> to accept them again or it might keep settings for some days even across 
> reboots.
> 
> Running in console does not seem to show relevant messages.
> 
> I must say my home is on NFSv4 (server also FreeBSD 12.2/amd64).
> 
> Any hint on where to look to solve this?

Firefox uses sqlite databases to store cookies, history and other items.
You should never store these on NFS. Ergo, put your profile folder on a
local filesystem.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: OpenJDK ports and 13-CURRENT

[Dimitry Andric]

On 10 Oct 2020, at 21:49, Shawn Webb  wrote:
> 
> On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote:
...
>> The quick way to work around these errors is to set -fcommon in CFLAGS,
>> which will basically fudge around the actual issue. The better way is to
>> get rid of the duplicated symbols. This is usually easy, except that
>> Java ports tend to take ages to build. :) I'll submit a patch when my
>> machine's finished crunching through it.
> 
> Yup. Another victim: print/tex-luatex:
> 
> https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/commit/229b7663bc82ff7e471dc1e19662f68d4226984a

I looked into this one finally, and it's not really an issue with any
recent clang import, as the PR is from 2018-12-20:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234221

The cause is a mixing of libstdc++ and libc++, which should not be done,
as it will almost always lead to unexpected linking errors.

The following diff fixes that:

Index: Makefile
===
--- Makefile(revision 552400)
+++ Makefile(working copy)
@@ -74,6 +74,8 @@ CONFIGURE_ARGS+=--with-system-$L \
--with-$L-include=${LOCALBASE}/include \
--with-$L-libdir=${LOCALBASE}/lib
 .endfor
+CONFIGURE_ARGS+=CC="${CC}" \
+   CXX="${CXX}"
 CPPFLAGS+= -I${LOCALBASE}/include
 MAKE_JOBS_UNSAFE=  yes
 TEX_FORMATS=   luatex


Note that the port's Makefile already has -fcommon added, to work
around duplicated symbols. Since the copy of texlive is ancient, it is
probably not worth the time to fix the actual issues.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: OpenJDK ports and 13-CURRENT

[Dimitry Andric]

On 11 Oct 2020, at 08:57, Yasuhiro KIMURA  wrote:
> 
> From: Yasuhiro KIMURA 
> Subject: Re: OpenJDK ports and 13-CURRENT
> Date: Sun, 11 Oct 2020 08:35:39 +0900 (JST)
> 
>>> Can you try the attached patch? I haven't yet looked at openjdk 13 and
>>> up, but I assume they will need at least the XSynchronize fix, and maybe
>>> the above ones, if the upstream branches were made after 2020-02-05.
>> 
>> I tried your patch but it fails at patch phase as following.
> 
> Sorry, I made a mistake. Your patch just works fine on 13-CURRENT
> amd64 r366578.

I submitted https://bugs.freebsd.org/250270, with patches for openjdk 12
through 15, and added a reference to https://bugs.freebsd.org/248756
which is the meta-bug for -fno-common issues.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: OpenJDK ports and 13-CURRENT

[Dimitry Andric]

On 10 Oct 2020, at 21:49, Shawn Webb  wrote:
> 
> On Sat, Oct 10, 2020 at 09:45:58PM +0200, Dimitry Andric wrote:
>> On 10 Oct 2020, at 21:23, Shawn Webb  wrote:
...
>>> Log of the HardenedBSD 13-CURRENT/amd64 package
>>> build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log
...
>> Ah, that is -fno-common fallout, strange that there is no build breakage
>> reported in the FreeBSD ports build cluster?

Ok, the -fno-common problems were already fixed by upstream in:

https://hg.openjdk.java.net/jdk/jdk/rev/6925fca95959
https://hg.openjdk.java.net/jdk/jdk/rev/9e54ea7d9cd9

but these apparently weren't ported back to openjdk 12.

The port also needed a fix for the awt wrapper for XSynchronize using
the wrong return type, e.g. it should use jlong instead of jint. This
should be upstreamed to the OpenJDK folks, as it is really a bug in the
JDK itself.

Can you try the attached patch? I haven't yet looked at openjdk 13 and
up, but I assume they will need at least the XSynchronize fix, and maybe
the above ones, if the upstream branches were made after 2020-02-05.

-Dimitry


java__openjdk12-fix-clang11-build-1.diff
Description: Binary data




signature.asc
Description: Message signed with OpenPGP

Re: OpenJDK ports and 13-CURRENT

[Dimitry Andric]

On 10 Oct 2020, at 21:23, Shawn Webb  wrote:
> 
> On Sat, Oct 10, 2020 at 09:18:08PM +0200, Dimitry Andric wrote:
>> On 10 Oct 2020, at 21:03, Shawn Webb  wrote:
>>> It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and
>>> above ports. Is anyone tracking this breakage?
>> 
>> Define "break". :) I can't find any PR, so I don't think so. The latest
>> builds on the ports cluster seem to have succeeded, but even though the
>> ports builder says "head-amd64-default-job", it appears to compile with
>> clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't
>> know.
> 
> Log of the HardenedBSD 13-CURRENT/amd64 package
> build:http://ci-03.md.hardenedbsd.org/data/hardenedbsd-13_amd64-local/2020-10-09_14h46m02s/logs/errors/openjdk12-12.0.2+10.4_1.log
> 
> HardenedBSD has switched to a full llvm compiler toolchain. I wonder
> if that's the culprit? Using llvm-ar, llvm-nm, et al.
> 
> Googling for the duplicate symbol error brought me this result:
> https://www.mail-archive.com/freebsd-pkg-fallout@freebsd.org/msg1544005.html

Ah, that is -fno-common fallout, strange that there is no build breakage
reported in the FreeBSD ports build cluster?

From gcc 10 and clang 11 onwards, -fno-common is the default (this is
really a historical mistake, -fcommon should never have been default).

It can result in link errors, if duplicate symbols exist in object
files. There is a suprising amount of software that makes this very
basic mistake!

The quick way to work around these errors is to set -fcommon in CFLAGS,
which will basically fudge around the actual issue. The better way is to
get rid of the duplicated symbols. This is usually easy, except that
Java ports tend to take ages to build. :) I'll submit a patch when my
machine's finished crunching through it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: OpenJDK ports and 13-CURRENT

[Dimitry Andric]

On 10 Oct 2020, at 21:03, Shawn Webb  wrote:
> It appears the latest import of llvm 11.0.0 breaks the OpenJDK 12 and
> above ports. Is anyone tracking this breakage?

Define "break". :) I can't find any PR, so I don't think so. The latest
builds on the ports cluster seem to have succeeded, but even though the
ports builder says "head-amd64-default-job", it appears to compile with
clang 8.0.1, for some reason. Might be incorrect, or on purpose, I don't
know.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Build error - cannot run C compiled programs

[Dimitry Andric]

On 27 Sep 2020, at 15:35, D'Arcy Cain  wrote:
> 
> I am trying to build zoom on FreeBSD and it is failing with the following
> error in audio/linux-c7-alsa-plugins-oss:
> 
> checking whether we are cross compiling... ELF binary type "0" not known.

The 'ELF binary type "0" not known' message indicates (rather poorly :)
that the kernel module for Linux has not been loaded.

Try running "kldload linux" and/or "kldload linux64" (if you require 64
bit Linux support) before building the port(s).

Once the ports are installed, add:

linux_enable="YES"

to your /etc/rc.conf, so support will be loaded at next boot.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: make a port use base llvm

[Dimitry Andric]

On 22 Sep 2020, at 20:16, tech-lists  wrote:
> 
> How can one make a port compile against base llvm? What would I need to do?

You can't. Use one of the llvm ports instead. Use precompiled binary
packages if your system is slow.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: x11-wm/piewm: "ld: error: duplicate symbol: yylineno"

[Dimitry Andric]

On 23 Aug 2020, at 21:35, David Wolfskill  wrote:
> 
> On Sun, Aug 23, 2020 at 06:39:10PM +, pkg-fall...@freebsd.org wrote:
>> You are receiving this mail as a port that you maintain
>> is failing to build on the FreeBSD package build server.
>> Please investigate the failure and submit a PR to fix
>> build.
>> 
>> Maintainer: da...@catwhisker.org
>> Last committer: swi...@freebsd.org
>> Ident:  $FreeBSD: head/x11-wm/piewm/Makefile 519608 2019-12-09 
>> 13:47:16Z swills $
>> Log URL:
>> http://beefy18.nyi.freebsd.org/data/head-amd64-default/p545731_s364466/logs/piewm-1.04_4.log
>> Build URL:  
>> http://beefy18.nyi.freebsd.org/build.html?mastername=head-amd64-default=p545731_s364466
>> ...
>> --- piewm ---
>> rm -f piewm
>> cc -o piewm   -L/usr/local/lib   gram.o lex.o deftwmrc.o add_window.o 
>> gc.o list.o twm.o  parse.o menus.o events.o resize.o util.o 
>> version.o iconmgr.ocursor.o icons.o vdt.o move.o LocPixmap.o 
>> -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXext -lXext -lX11 -lm 
>> -ll -lXpm  -Wl,-rpath,/usr/local/lib
>> ld: error: duplicate symbol: yylineno
> defined at gram.c
>   gram.o:(yylineno)
> defined at lex.c
>   lex.o:(.data+0x0)
>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>> *** [piewm] Error code 1
>> 
>> make[1]: stopped in /wrkdirs/usr/ports/x11-wm/piewm/work/piewm-1.04
>> 1 error
>> 
>> make[1]: stopped in /wrkdirs/usr/ports/x11-wm/piewm/work/piewm-1.04
>> ===> 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/x11-wm/piewm
> 
> So... I confess a lack of familiarity with lex, yacc, and their
> work-alikes.  It also appears that x11-wm/tvtwm (for which MAINTAINER is
> this list -- po...@freebsd.org) is likely similarly affected.
> 
> I understand that the immediate cause is a recent change; in
> http://docs.FreeBSD.org/cgi/mid.cgi?B7F9F85B-60A4-4A87-9911-BDE1CBC7BC91,
> dim@ mentioned:
> 
> | This is because clang 11 (and gcc 10) now default to -fno-common. The
> | rationale is explained pretty well in...
> 
> and goes on to state:
> | A quick fix is to add CFLAGS+=-fcommon to your make.conf, but that is
> | rather a big hammer. It is better to add it to just the ports that show
> | problems due to duplicated symbols. And ideally, those duplicated
> | symbols should be patched out of the ports.
> 
> So:  apparently *a* way around this is to change the Makefile (to
> include 'CFLAGS+=-fcommon') -- but I don't know if a "better" approach
> is feasible: we are dealing with some rather old (or, perhaps,
> "well-established") code, here.
> 
> Advice/suggestions?

In this case, "svn rm x11-wm/piewm/files/patch-gram.y" will fix it
correctly. I have no idea why that patch was added in the first place,
it is clearly incorrect!

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: pkg-fallout: duplicate symbols?

[Dimitry Andric]

On 22 Aug 2020, at 16:05, Christian Weisgerber  wrote:
> 
> I'm currently receiving pkg-fallout mail that some of the ports I
> maintain are failing to build with "duplicate symbol" errors.

See .

This is because clang 11 defaults to -fno-common now, causing some
programs that incorrectly define multiple copies of the same global
variables to no longer link.

It can be worked around by adding -fcommon to the compilation flags, but
in most cases it should not be too difficult to get rid of the multiply
defined symbols.


> It is unclear to me whether these are actual problems I need to
> take care of, or just some kind of screw-up on the package build
> server.  This part of each message doesn't inspire confidence:
> 
> !!! Jail is newer than host. (Jail: 1300110, Host: 1300100) !!!
> !!! This is not supported. !!!
> !!! Host kernel must be same or newer than jail. !!!
> !!! Expect build failures. !!!

Yeah, this warning is seen all the time, and while it sounds very
ominous, there is not much you can do about it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: mail/filtermail fails to build with 13.0-CURRENT

[Dimitry Andric]

On 27 Jun 2020, at 17:56, Mike Clarke  wrote:
> As someone with very little experience with C++ I'd welcome advice on how to 
> fix this for 13.0-
> CURRENT. It builds without problem on 12.1-RELEASE
...
> rcfile.ll:151:14: error: no viable overloaded '='
>yyin = new ifstream (sub_file.c_str ());
> ^ 

This appears to be caused by a recent update to contrib/flex from 2.5.37 (7 
years old) to 2.6.4, in r362333, where upstream changed yyin and yyout from 
pointers to references:

https://github.com/westes/flex/commit/336a1deaa57975f34cd732d656d1c0cbe3d5233a

Unfortunately this can break existing .ll files. They will have to be patched, 
but this is made more difficult by having the new version of flex in 13-CURRENT.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: LLVM target 'amdgpu' not enabled Was: Re: Conflict on very first port (xorg) on rpi3

[Dimitry Andric]

On 16 May 2020, at 17:44, bob prohaska  wrote:
> 
> Deinstalling the conflicting port made considerable progress toward a build of
> x11/xorg, but now make is stopping with:
> 
> configure: error: LLVM target 'amdgpu' not enabled in your LLVM build. 
> Required by radv.
> 
> I've tried turning off Wayland support in graphics/mesa-dri but that didn't 
> help.
> 
> Since this is on a Raspberry Pi3B, one wouldn't really expect to find an AMD 
> GPU,
> 
> If there's a workaround please give me a hint

It seems to be required by the ATI/AMD Radeon drivers, and there is no
option to turn these drivers off, as far as I can see. You could attempt
to edit graphics/mesa-dri/Makefile, and fiddle with the ALL_DRI_DRIVERS,
ALL_GALLIUM_DRIVERS and ALL_VULKAN_DRIVERS lines. But this is going to
be very fragile, the best solution is really to rebuild the llvm port
with AMDGPU support.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: python 2.7 marked as deprecated and EOL while 2.7.18 RC is available

[Dimitry Andric]

On 17 Apr 2020, at 14:11, Dewayne Geraghty  wrote:
> 
> Its very confusing building ports at the moment.  At https://www.python.org/
> there is a release candidate for 2.7.18, while our python 2.7 has been
> marked as deprecated with an expiration date.  Can the Expiration Date of
> 2020-12-31 be retracted?
> 
> It appears that devel/scons, at least, requires python 2.7 to run; though
> it builds with 3.7.

See https://www.python.org/dev/peps/pep-0373/; python 2.x is now really
dead, and has been since 2020-01-01.

But it is unfortunately terribly confusing for end-users that they're
apparently still planning on shipping another "really final final"
2.7.18 version. A petition against this bad idea is here:

https://discuss.python.org/t/petition-abandon-plans-to-ship-a-2-7-18-in-april/2946

But basically, expect all python 2.x using ports to go away, unless they
get fixed to use python 3.x, or no python at all.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: editors/atom: build error on 13.0-CURRENT

[Dimitry Andric]

On 15 Apr 2020, at 22:14, Vidar Karlsen  wrote:
> 
> I'm getting an error building editors/atom on 13.0-CURRENT:
>> ===>  Building for atom-ide-1.45.0
>> cd /usr/ports/editors/atom/work/node-v10.2.1 [...]
>> WARNING: C++ compiler too old, need g++ 4.9.4 or clang++ 3.4.2 (CXX=c++)
>> ERROR: Did not find a new enough assembler, install one or build with
>>   --openssl-no-asm.
>>   Please refer to BUILDING.md
> 
> Adding --openssl-no-asm to the ./configure line (Makefile line 115) seems to 
> bypass the problem, and it builds, runs and works fine as far as I can see, 
> but I don't know if this can affect some of the functionality.
> 
> BUILDING.md says it needs llvm 3.3 or higher, and I have clang 10.0.0. Is 
> this simply a version check gone wrong in node?

Very likely. When FreeBSD went to version 10, lots of sloppy configure
scripts then started to assume they were dealing with FreeBSD 1.x, and
did *strange* things. I would look for an expression "1*" in the
script. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: print/libraqm failed in

[Dimitry Andric]

On 11 Apr 2020, at 04:35, KIRIYAMA Kazuhiko  wrote:
> 
> print/libraqm failed to build:
...
> raqm.c:1934:24: error: overlapping comparisons always evaluate to true 
> [-Werror,-Wtautological-overlap-compare]
>  if (ch != 0x102B || ch != 0x102C || ch != 0x1038 ||
>  ~^~~
> raqm.c:1937:25: error: overlapping comparisons always evaluate to false 
> [-Werror,-Wtautological-overlap-compare]
>  (ch <= 0x109A && ch >= 0x109C) || ch != 0x1A61 || ch != 0x1A63 ||
>   ~^~~
> raqm.c:1936:41: error: overlapping comparisons always evaluate to false 
> [-Werror,-Wtautological-overlap-compare]
>  ch != 0x1083 || (ch <= 0x1087 && ch >= 0x108C) || ch != 0x108F ||
>   ~^~~
> raqm.c:1935:59: error: overlapping comparisons always evaluate to false 
> [-Werror,-Wtautological-overlap-compare]
>  (ch <= 0x1062 && ch >= 0x1064) || (ch <= 0x1067 && ch >= 0x106D) ||
> ~^~~
> raqm.c:1935:25: error: overlapping comparisons always evaluate to false 
> [-Werror,-Wtautological-overlap-compare]
>  (ch <= 0x1062 && ch >= 0x1064) || (ch <= 0x1067 && ch >= 0x106D) ||
>   ~^~~

See:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244401
https://github.com/HOST-Oman/libraqm/issues/115

and finally:

https://svnweb.freebsd.org/changeset/ports/530379

Author: zeising
Date: Thu Apr  2 15:05:52 UTC 2020
New revision: 530379

Log:
  print/libraqm: FIx build with llvm 10

  Fix the build of print/libraqm with llvm 10.

  PR:   244401
  Submitted by: dim
  Approved by:  maintainer timeout
  MFH:  2020Q2

Changes:
  head/print/libraqm/files/patch-src_raqm.c

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: fetch is tarpitted by Texas Instruments and/or Akamai and can not download distfiles for TI-related ports.

[Dimitry Andric]

On 3 Apr 2020, at 15:08, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> It is true for both IPv4 and IPv6, and for Russia and Germany (I can
>> not test from USA, though).
> 
> I tried it from freefall, same problem.

Typically one of those "Endpoint Protection" products, they have some sort of 
whitelist or blacklist of bad user agents. Using "curl/7.68.0" as user agent 
works:

$ fetch -vvv --user-agent="curl/7.68.0" 
http://www.ti.com/lit/ug/slau646e/slau646e.pdf
scheme:   "http"
user: ""
password: ""
host: "www.ti.com"
port: "0"
document: "/lit/ug/slau646e/slau646e.pdf"
---> www.ti.com:80
resolving server address: www.ti.com:80
requesting http://www.ti.com/lit/ug/slau646e/slau646e.pdf
>>> GET /lit/ug/slau646e/slau646e.pdf HTTP/1.1
>>> Host: www.ti.com
>>> Accept: */*
>>> User-Agent: curl/7.68.0
>>> Connection: close
>>>
<<< HTTP/1.1 200 OK
<<< Server: Apache
<<< Last-Modified: Wed, 26 Jun 2019 21:34:37 GMT
<<< ETag: "1551ab-58c40cfeb6c6f"
last modified: [2019-06-26 21:34:37]
<<< Accept-Ranges: bytes
<<< Content-Length: 1397163
<<< Cache-Control: max-age=60
content length: [1397163]
<<< Expires: Thu, 30 Jan 2020 09:27:51 GMT
<<< Content-Type: application/pdf
<<< Date: Fri, 03 Apr 2020 17:30:20 GMT
<<< Connection: close
<<< Set-Cookie: ti_geo=country=XX|city=YYY|continent=EU|tc_ip=n.m.o.p; 
path=/; domain=.ti.com
<<< Set-Cookie: ti_rid=3110b500; path=/; domain=.ti.com
<<< Set-Cookie: ti_ua=curl%2f7.68.0; path=/; domain=.ti.com
<<< Set-Cookie: ti_ak_id=67fba42067fba42067fba4205e8772ac3110b500; expires=Sat, 
03-Apr-2021 17:30:20 GMT; path=/; domain=.ti.com
<<< Set-Cookie: ti_ridh=expired; path=/; domain=ti.com; expires=Thu, 1-Aug-2019 
06:14:04 GMT
<<< Set-Cookie: ti_bm=; path=/; domain=.ti.com
<<<
offset 0, length -1, size -1, clength 1397163
local size / mtime: 1397163 / 1585934997
remote size / mtime: 1397163 / 1561584877
slau646e.pdf  1364 kB   15 MBps00s

You can immediately see they're trying to violate cookie laws. ;-)  The "ti_ua" 
cookie stores the user agent, and I guess "tk_ak_id" is the Akamai ID (a.k.a. 
personally identifiable information).

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: current: cd /lib ; ln -s libncurses.so.9 libncurses.so.8 xterm & ffox

[Dimitry Andric]

On 2 Apr 2020, at 09:59, Baptiste Daroussin  wrote:
> 
> On Wed, Apr 01, 2020 at 08:01:35PM +0200, Dimitry Andric wrote:
>> On 2020-04-01 02:22, Julian H. Stacey wrote:
>>> Hi ports@
>>> A libcurses version problem:
>>> 
>>> Running 13.0-CURRENT with
>>> /usr/src
>>>  cat .svn_revision 359319
>>>  cat .ctm_status src-cur 14430
>>> /usr/ports
>>>  cat .svn_revision 529842
>>>  cat .ctm_status ports-cur 13423
>>> 
>>> After
>>>  pkg upgrade
>>>  pkg autoremove
>>> xterm & firefox failed with
>>>  ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "xterm"
>> ...
>>> Next to look at /usr/src/
>>> ObsoleteFiles.inc
>>> # 20200220: Upgrade of ncurses, shlib bumped to version 9
>>> OLD_LIBS+=lib/libncurses.so.8
>> 
>> Yeah, this ncurses bump was handled pretty badly, as it breaks almost all
>> installed ports (and a bunch of base programs too, if you are unlucky).
>> Isn't there any compat package for it yet?
>> 
>> -Dimitry
> ??
> 
> When the bump occured a month ago, an UPDATING entry was added as usual to 
> warn
> everyone, a compat12x package has been created immediatly and all the packages
> have been rebuilt. What else could have been done? Can you explain me what I
> have badly done here?

Sorry about that, I realized that I was totally off-base here.  At that
time I was simply annoyed that I had to rebuild all my ports againn, as
I mostly don't use packages.  And I wasn't aware ncurses was added to
the compat12 package, I simply backed up my old ncurses.so.8
everywhere...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: current: cd /lib ; ln -s libncurses.so.9 libncurses.so.8 xterm & ffox

[Dimitry Andric]

On 2020-04-01 02:22, Julian H. Stacey wrote:

Hi ports@
A libcurses version problem:

Running 13.0-CURRENT with
/usr/src
  cat .svn_revision 359319
  cat .ctm_status src-cur 14430
/usr/ports
  cat .svn_revision 529842
  cat .ctm_status ports-cur 13423

After
  pkg upgrade
  pkg autoremove
xterm & firefox failed with
  ld-elf.so.1: Shared object "libncurses.so.8" not found, required by "xterm"

...

Next to look at /usr/src/
ObsoleteFiles.inc
# 20200220: Upgrade of ncurses, shlib bumped to version 9
OLD_LIBS+=lib/libncurses.so.8


Yeah, this ncurses bump was handled pretty badly, as it breaks almost 
all installed ports (and a bunch of base programs too, if you are 
unlucky). Isn't there any compat package for it yet?


-Dimitry
___
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: 2.32 assertion fail elflink.c:2935 on RPi2

[Dimitry Andric]

On 15 Apr 2019, at 06:30, bob prohaska  wrote:
> 
> Attempts to build www/firefox on rpi2 fail during compilation of
> llvm60, with
> 
> /usr/local/bin/ld: BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935
> 
> There don't seem to be any other error messages in the build output.
> Swap usage peaks at 16%, vm.pageout_oom_seq=2048 .
> 
> The machine is running
> FreeBSD www.zefox.com 11.2-STABLE FreeBSD 11.2-STABLE #2 r345473: Sun Mar 24 
> 08:57:56 PDT 2019 b...@www.zefox.com:/usr/obj/usr/src/sys/RPI2  arm
> 
> with ports at 498696.
> 
> Thanks for reading and any suggestions.

Likely a BFD ld bug, but see: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237068

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Clang crash compiling qt5

[Dimitry Andric]

On 10 Apr 2019, at 21:29, George Mitchell  wrote:
> 
> On 2019-04-10 15:11, Dimitry Andric wrote:
>> On 10 Apr 2019, at 19:37, George Mitchell  wrote:
>>> 
>>> Yesterday I went through a round of updating and compiling ports.  By
>>> all outward appearances it was successful.  But this morning's daily
>>> status report revealed that clang had crashed on a signal 11 once
>>> while compiling each qt5 package.  (For once, it was useful to have
>>> the "such-and-such installed" messages in the system log.)  So I just
>>> tried recompiling qt5-qmake just now under "script".  Sure enough,
>>> there was a clang crash about 15 seconds before the end of typescript,
>>> though the typescript output looks completely innocuous as far as I
>>> can see, and all the qt5 packages and their dependencies seem to be
>>> functional at this point.  Any idea about what's going on?
>>> 
>>> The typescript output is at https://m5p.com/~george/typescript if
>>> you think it would be helpful.-- George
>> 
>> Hi George,
>> 
>> I don't see any crash report(s) in the typescript?  Did clang drop two
>> files (a .sh and preprocessed .c or .cpp file) in /tmp, by any chance?
>> 
> 
> Yes, it did -- quite a few of them.  The 13 .cpp files are all
> identical.  The .sh files are very similar but not identical.  I
> attached one.  Running it indeed causes another core dump.  It
> sort of looks like it happened during a configuration step.

Okay, can you create a PR and attach one .sh and .cpp file which belong
together (they should have the same random suffix of hex digits)?  It is
likely that we can then reproduce it independently of your particular
setup, and without having to build qt5 and all its dependencies. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Clang crash compiling qt5

[Dimitry Andric]

On 10 Apr 2019, at 19:37, George Mitchell  wrote:
> 
> Yesterday I went through a round of updating and compiling ports.  By
> all outward appearances it was successful.  But this morning's daily
> status report revealed that clang had crashed on a signal 11 once
> while compiling each qt5 package.  (For once, it was useful to have
> the "such-and-such installed" messages in the system log.)  So I just
> tried recompiling qt5-qmake just now under "script".  Sure enough,
> there was a clang crash about 15 seconds before the end of typescript,
> though the typescript output looks completely innocuous as far as I
> can see, and all the qt5 packages and their dependencies seem to be
> functional at this point.  Any idea about what's going on?
> 
> The typescript output is at https://m5p.com/~george/typescript if
> you think it would be helpful.-- George

Hi George,

I don't see any crash report(s) in the typescript?  Did clang drop two
files (a .sh and preprocessed .c or .cpp file) in /tmp, by any chance?

If you are using a stable branch, clang will not have been built with
assertions, and that can lead to crashes in some cases.  You could try
commenting out the -DNDEBUG line in lib/clang/llvm.build.mk, and then
rebuilding and reinstalling world.  Then try the port again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Clang Import Breakage

[Dimitry Andric]

On 24 Mar 2019, at 00:22, Sean Bruno  wrote:
> 
> audio/shout-idjc seems to have broken in a new and exciting way after
> the 8.0 import.
> 
> It would appear that the ports infrastructure detects libssl and libogg
> exist (if the beginning of my logs are to be believed) but then are not
> used during libtool/LD stages later on resulting in missing symbols.
> This does not happen prior to the import so I am assuming I am missing
> something explicit here.
> 
> http://beefy12.nyi.freebsd.org/data/head-amd64-default/p496405_s345355/logs/errors/libshout-idjc-2.4.2.log

This is fallout of ,
which enabled --no-allow-shlib-undefined by default.  See also
.  Executive summary: lots of programs
do not specify all their required libraries, a.k.a. "under-linking".

I haven't yet reverted lld's new default, since it seems that a lot of
under-linking fixes are now being made.  These problems will also occur
when linking with gold, for instance, so it is quite useful to solve
them once and for all.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: LLVM 7.1.0: how to proceed?

[Dimitry Andric]

On 6 Feb 2019, at 19:58, Brooks Davis  wrote:
> LLVM 7.1.0 will be release shortly and contains a single
> fix which breaks the LLVM Libra ABI in order to fix an
> incompatibility with GCC 8.2.  A bug describing the issue is at
> https://bugs.llvm.org/show_bug.cgi?id=39427.
> 
> My current plan is:
> - Copy devel/llvm70 to devel/llvm71 and update.
> - Perform a coordinated switch of all dependencies, to llvm71 (e.g. do an
>   exp-run with the switch made and llvm70 removed).  All ports with
>   library dependencies would get PORT_REVISION bumps.
> - DEPRECATE llvm70 and set a short expiration.
> 
> Does this sound like a reasonable plan?

If you were going to drop llvm70 anyway, why not just keep the port and
only bump the 'internal' version number?  Or do you want to reduce
possible confusion which might be caused by the "70" suffix no longer
corresponding to the actual libllvm.so version number?

That said, your approach seems fine to me.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Config inconsistency for firefox-esr on rpi2

[Dimitry Andric]

On 24 Feb 2019, at 18:28, bob prohaska  wrote:
> 
> In playing with www/firefox-esr on an rpi2 at r343555 using
> ports at 493769 make stops with
> 
> ===>  Configuring for firefox-esr-52.8.0,1
> firefox-esr-52.8.0,1: Needs gtk3 with WAYLAND support enabled.
> *** Error code 1
> 
> despite both wayland and gtk3 being selected in the config dialog.
> 
> I've retried several times, the error persists.

This actually means that you have to rebuild the *gtk3* port with
WAYLAND enabled.  It could be worded a little better, maybe. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: vulnerabilities bogus error

[Dimitry Andric]

On 14 Dec 2018, at 22:40, Ernie Luzar  wrote:
> 
> Trying to update my port. During make install get a bunch of bogus error 
> messages about the port having vulnerabilities. I know this to not be the 
> case. The first message says
> pkg-static; unable to open vulnxml file (null): Invalid argument
> 
> This is a new fresh install of RELEASE 12.0. How do I manually fetch this 
> vulnxml file or where should I "touch" to create it?

Run "pkg audit -F".

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: More troubles building www/epiphany

[Dimitry Andric]

On 10 Nov 2018, at 22:59, bob prohaska  wrote:
> 
> Now that webkit2-gtk3 compiles correctly make in www/epiphany stops on what 
> looks like a
> version of the openssl upgrade problem:
> 
> ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0 required by 
> /usr/local/lib/libarchive.so.13 not defined
> Command 
> '['/usr/ports/devel/appstream-glib/work/appstream-glib-0.7.8/_build/tmp-introspect4zt426i5/AppStreamGlib-1.0',
>  
> '--introspect-dump=/usr/ports/devel/appstream-glib/work/appstream-glib-0.7.8/_build/tmp-introspect4zt426i5/functions.txt,/usr/ports/devel/appstream-glib/work/appstream-glib-0.7.8/_build/tmp-introspect4zt426i5/dump.xml']'
>  returned non-zero exit status 1.
> ninja: build stopped: subcommand failed.
...
> What's the best way to proceed? I started to compile security/openssl111
> but was greeted by an immediate conflict warning with no obvious resolution.
> 
> The system is at
> FreeBSD 13.0-CURRENT r340325 GENERIC  arm64

After r339270 (the upgrade of base OpenSSL to 1.1.1) and r339709
(bumping of OpenSSL shared libraries to version 111), you must delete
all your ports, and rebuild them from scratch.

Yes, it sucks. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: devel/llvm60 build failure in poudriere

[Dimitry Andric]

On 2 Nov 2018, at 01:56, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> I am trying to build iridium-browser which dependes on llvm60, but my 
> poudriere cannot build llvm60 with the following error:
> 
> ===
> ===> Fetching all distfiles required by llvm60-6.0.1_3 for building
> => SHA256 Checksum OK for llvm-6.0.1.src.tar.xz.
> => SHA256 Checksum OK for cfe-6.0.1.src.tar.xz.
> ===
> ===
> ===
> ===
> ===> Fetching all distfiles required by llvm60-6.0.1_3 for building
> ===>  Extracting for llvm60-6.0.1_3
> => SHA256 Checksum OK for llvm-6.0.1.src.tar.xz.
> => SHA256 Checksum OK for cfe-6.0.1.src.tar.xz.
> /bin/mv /wrkdirs/usr/ports/devel/llvm60/work/cfe-6.0.1.src 
> /wrkdirs/usr/ports/devel/llvm60/work/llvm-6.0.1.src/tools/clang
> ===
> ===
> ===
> ===
> ===>  Patching for llvm60-6.0.1_3
> ===>  Applying extra patch /usr/ports/devel/llvm60/files/clang
>  I can't seem to find a patch in there anywhere.
> *** Error code 2
> 
> Stop.
> make: stopped in /usr/ports/devel/llvm60
> =>> Cleaning up wrkdir
> ===>  Cleaning for llvm60-6.0.1_3
> build of devel/llvm60 | llvm60-6.0.1_3 ended at Fri Nov  2 01:50:44 CET 2018
> build time: 00:00:10
> !!! build failure encountered !!!
> 
> 
> OS on the host is 11.2 amd64, building jail is 10.4 amd64
> 
> I tried selec or unselect all options in dialog for llvm60 but it didn't help.
> 
> What  does the error "I can't seem to find a patch in there anywhere" mean?

It means that one of the patch files in your port checkout has been
corrupted, and the patch utility is not able to interpret it anymore.

You should first check whether your ports tree is cleanly checked out,
revert any local changes, and then try again.  If that fails too, delete
the ports tree, and check it out from scratch.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: sshguard - rc and blacklisting

[Dimitry Andric]

On 15 Oct 2018, at 17:16, Per olof Ljungmark  wrote:
> 
> Either I am doing it wrong or sshguard is not properly implemented.
> 
> 1. In the config file /usr/local/etc/sshguard.conf there is a parameter
> 
> # Colon-separated blacklist threshold and full path to blacklist file.
> # (optional, no default)
> #BLACKLIST_FILE=120:/var/db/sshguard/blacklist.db
> 
> however, the threshold setting does not seem to have any effect. If I
> change the setting in rc.d/sshguard, it does take effect.

Yes, this is a problem in /usr/local/etc/rc.d/sshguard.  It sets the
default sshguard_blacklist setting to 120:/var/db/sshguard/blacklist.
To work around it, I have put:

sshguard_blacklist=""

in my rc.conf.  Then only the settings in sshguard.conf are used.



> 2. Looking at /var/db/sshguard/blacklist.db, each row looks like
> 1539615075|220|4|143.0.65.92
> 
> There is another setting in the config,
> # Size of IPv4 subnet to block. Defaults to a single address, CIDR
> notation. (optional, default to 32)
> IPV4_SUBNET=32
> 
> I have tried to alter this setting to /24 and /29, auth.log says
> Blocking "143.0.65.92/29" forever
> but blacklist.db does not indiciate any different CDIR than /32.

I have no experience with this setting, and it seems to be pretty new.
It was not in my sample config file until quite recently, maybe it is
an upstream problem?  Have you looked at their bug tracker?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Removing git dependencies on perl5 and python27

[Dimitry Andric]

On 17 Jun 2018, at 00:04, Mahmoud Al-Qudsi  wrote:
> 
> On Fri, Jun 15, 2018 at 3:24 AM, Franco Fichtner  wrote:
>> The bottom line is that excluding Perl and Python support from git
>> will make it only usable for automated shell scripting.
>> 
>> Interactive parts require Perl or Python so there is nothing to be
>> gained from breaking POLA for existing users of the git FreeBSD
>> package or git software in general as any random tutorial out there
>> may not work for FreeBSD anymore.
>> 
>> For emphasis, this is suboptimal at best...
> 
> I did not realize that even basic functionality like `git add -i` required
> perl; I am very surprised that isn't implemented in C (at least by now).

Git was started as a random collection of perl scripts, shell scripts
and a smattering of C sources originally. Since there is no (or does not
seem to be) any overall architecture, it does not seem likely that this
will ever be solved. :)


> Personally speaking, it is the dependency on python27 rather than perl5 that I
> find more distasteful (due to the size and scope). Do you know what features
> python unlocks? (Not that this proposal has half as much bite if perl5 is
> retained..)

You can disable the python dependency by unchecking the CONTRIB and P4
port options.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: port x11-wm/icewm does not have a pkg?

[Dimitry Andric]

On 3 May 2018, at 17:16, Mateusz Piotrowski <0...@freebsd.org> wrote:
> 
> On Thu, 03 May 2018 12:50:24 +0200
> "Ronald Klop"  wrote:
> 
>> I can't install a pkg of x11-wm/icewm. But I can't see in the port
>> why. It seems to have a proper license GPLv2 and is distributable.
> 
> It looks like it's simply broken because it does not compile probably
> due to the switch to a C++11.
> 
> I've opened an issue on Bugzilla for this.[1]

I submitted a patch, which simply adds USE_CXXSTD=gnu++98 to the port Makefile.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Dimitry Andric]

On 3 Apr 2018, at 21:27, Michael Grimm <trash...@ellael.org> wrote:
> 
> Dimitry Andric <d...@freebsd.org> wrote:
>>> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:
> 
>>> With "USE_CXXSTD=gnu++98" added into that port's Makefile poudriere has 
>>> been able to compile that port. Thank you.
>> 
>> Alternatively, please try the patch in <https://bugs.freebsd.org/227209>.
> 
> But that patch addresses geomWatch and not mariadb102-server, right?

Sorry, pasted the wrong link.  Try this instead: 
<https://bugs.freebsd.org/227244>.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 11.1-STABLE #0 r331865: geomWatch compilation fails

[Dimitry Andric]

On 3 Apr 2018, at 21:23, Michael Grimm <trash...@ellael.org> wrote:
> 
> Dimitry Andric <d...@freebsd.org> wrote:
>> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:
> 
>>> Well, this time, after adding "USE_CXXSTD=gnu++98" into that port's 
>>> Makefile, poudriere has not been able to compile that port. Sadly. But 
>>> thank you anyway.
>> 
>> Please try the patches in <https://bugs.freebsd.org/227209>.
> 
> I did apply your patch "Make geomWatch obey USE_CXXSTD=gnu++98 option" to 
> sysutils/geomWatch/files/patch-Makefile and "USE_CXXSTD=gnu++98" to 
> sysutils/geomWatch/Makefile, and it compiles successfully. Thanks.
> 
> P.S. Do you want me to apply Harald's patch "zfs-sysevent.h: Insert 
> whitespaces for C++11 compile werror." in addition and/or as well?

Either Harald's patch, or mine, both is superfluous.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Dimitry Andric]

> On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:
> 
> Dimitry Andric <d...@freebsd.org> wrote:
>> On 2 Apr 2018, at 21:40, Michael Grimm <trash...@ellael.org> wrote:
> 
>>> since the recent upgrade of llvm et al in STABLE-11.1 
>>> mariadb102-server-10.2.14  fails to compile (poudriere):
>>> 
>>> --- storage/connect/CMakeFiles/connect.dir/all ---
>>> --- storage/connect/CMakeFiles/connect.dir/table.cpp.o ---
>>> --- storage/connect/CMakeFiles/connect.dir/tabjson.cpp.o ---
>>> /wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:198:10:
>>>  error: cannot initialize return object of type 'int' with an rvalue of 
>>> type 'nullptr_t'
>>>  return NULL;
>>> ^~~~
>> 
>> The code is likely buggy, but you can try adding USE_CXXSTD=gnu++98 in
>> the port Makefile as a workaround.
> 
> With "USE_CXXSTD=gnu++98" added into that port's Makefile poudriere has been 
> able to compile that port. Thank you.

Alternatively, please try the patch in <https://bugs.freebsd.org/227209>.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 11.1-STABLE #0 r331865: geomWatch compilation fails

[Dimitry Andric]

On 3 Apr 2018, at 19:34, Michael Grimm <trash...@ellael.org> wrote:
> 
> Dimitry Andric <d...@freebsd.org> wrote:
>> On 2 Apr 2018, at 21:33, Michael Grimm <trash...@ellael.org> wrote:
>>> since the recent upgrade of llvm et al in STABLE-11.1 geomWatch fails to 
>>> compile (poudriere):
>>> 
>>> In file included from geomWatch.cpp:41:
>>> In file included from ./zpool.hpp:35:
>>> In file included from 
>>> zfs/v28/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h:38:
>>> In file included from 
>>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h:30:
>>> In file included from 
>>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h:29:
>>> In file included from 
>>> zfs/v28/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:83:
>>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:79:37: 
>>> error: invalid suffix on literal; C++11 requires a space between literal 
>>> and identifier [-Wreserved-user-defined-literal]
>>> #define SUNW_KERN_PUB   SUNW_VENDOR":"SE_KERN_PUB
>>>^
>>> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:80:36: 
>>> error: invalid suffix on literal; C++11 requires a space between literal 
>>> and identifier [-Wreserved-user-defined-literal]
>>> #define SUNW_USR_PUBSUNW_VENDOR":"SE_USR_PUB
>>>^
>> 
>> This can be fixed either by adding spaces before the double quotes, or
>> it can be worked around by adding USE_CXXSTD=gnu++98 in the port
>> Makefile.
> 
> Well, this time, after adding "USE_CXXSTD=gnu++98" into that port's Makefile, 
> poudriere has not been able to compile that port. Sadly. But thank you anyway.

Please try the patches in <https://bugs.freebsd.org/227209>.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 11.1-STABLE #0 r331865: geomWatch compilation fails

[Dimitry Andric]

On 2 Apr 2018, at 21:33, Michael Grimm  wrote:
> 
> since the recent upgrade of llvm et al in STABLE-11.1 geomWatch fails to 
> compile (poudriere):
> 
> In file included from geomWatch.cpp:41:
> In file included from ./zpool.hpp:35:
> In file included from 
> zfs/v28/cddl/contrib/opensolaris/lib/libzfs/common/libzfs.h:38:
> In file included from 
> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_ioctl.h:30:
> In file included from 
> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h:29:
> In file included from 
> zfs/v28/cddl/contrib/opensolaris/lib/libzpool/common/sys/zfs_context.h:83:
> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:79:37: error: 
> invalid suffix on literal; C++11 requires a space between literal and 
> identifier [-Wreserved-user-defined-literal]
> #define SUNW_KERN_PUB   SUNW_VENDOR":"SE_KERN_PUB
>  ^
> 
> zfs/v28/sys/cddl/contrib/opensolaris/uts/common/sys/sysevent.h:80:36: error: 
> invalid suffix on literal; C++11 requires a space between literal and 
> identifier [-Wreserved-user-defined-literal]
> #define SUNW_USR_PUBSUNW_VENDOR":"SE_USR_PUB
>  ^

This can be fixed either by adding spaces before the double quotes, or
it can be worked around by adding USE_CXXSTD=gnu++98 in the port
Makefile.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD 11.1-STABLE #0 r331865: mariadb102-server-10.2.14 compilation fails

[Dimitry Andric]

On 2 Apr 2018, at 21:40, Michael Grimm  wrote:
> 
> since the recent upgrade of llvm et al in STABLE-11.1 
> mariadb102-server-10.2.14  fails to compile (poudriere):
> 
> 
> 
> --- storage/connect/CMakeFiles/connect.dir/all ---
> --- storage/connect/CMakeFiles/connect.dir/table.cpp.o ---
> --- storage/connect/CMakeFiles/connect.dir/tabjson.cpp.o ---
> /wrkdirs/usr/ports/databases/mariadb102-server/work/mariadb-10.2.14/storage/connect/tabjson.cpp:198:10:
>  error: cannot initialize return object of type 'int' with an rvalue of type 
> 'nullptr_t'
>return NULL;
>   ^~~~

The code is likely buggy, but you can try adding USE_CXXSTD=gnu++98 in
the port Makefile as a workaround.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: devel/arm-none-eabi-gcc fails to build on 11-stable

[Dimitry Andric]

On 15 Mar 2018, at 17:00, tech-lists <tech-li...@zyxst.net> wrote:
> 
> On 15/03/2018 10:26, Dimitry Andric wrote:
>> On 14 Mar 2018, at 23:07, Dimitry Andric <d...@freebsd.org> wrote:
>>> 
>>> On 14 Mar 2018, at 14:46, tech-lists <tech-li...@zyxst.net> wrote:
>> ...
>>>> In file included from
>>>> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/genpreds.c:26:
>>>> In file included from ./tm.h:17:
>>>> ./options.h:5327:3: error: redefinition of enumerator 'OPT_C'
>>>> OPT_C = 127,   /* -C */
>>>> ^
>>> 
>>> Try building the port with LANG=C in your environment.  If I recall
>>> correctly, this was some problem with sed in combination with non-C
>>> language settings.
>> 
>> 
>> See also: https://bugs.freebsd.org/215882
>> and: https://svnweb.freebsd.org/changeset/ports/431796
>> 
>> It looks like some of the gcc ports were not updated for this issue.
> 
> Hi Dimitry, thank you for your help.
> 
> It seems not just LANG=C was required because it failed if I just did
> that. In the end, this was needed (shell is bash here)
> 
> mv /etc/make.conf /etc/make-20180315.conf
> set LANG=C
> export LANG
> set LC_ALL=C
> export LC_ALL
> 
> [then make clean && make install]
> 
> maybe I caused the problem. My make.conf usually has
> USE_LOCALE=en_GB.UTF-8 in it. What should I do in this circumstance -
> not use USE_LOCALE=en_GB.UTF-8 in /etc/make.conf or raise (or re-open if
> I can) a/that bug report?

I would create a new PR with "devel/arm-none-eabi-gcc" in the title, so
it gets assigned to the maintainer automagically, and refer to bug
215882 for more information.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: devel/arm-none-eabi-gcc fails to build on 11-stable

[Dimitry Andric]

On 14 Mar 2018, at 23:07, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 14 Mar 2018, at 14:46, tech-lists <tech-li...@zyxst.net> wrote:
...
>> In file included from
>> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/genpreds.c:26:
>> In file included from ./tm.h:17:
>> ./options.h:5327:3: error: redefinition of enumerator 'OPT_C'
>> OPT_C = 127,   /* -C */
>> ^
> 
> Try building the port with LANG=C in your environment.  If I recall
> correctly, this was some problem with sed in combination with non-C
> language settings.


See also: https://bugs.freebsd.org/215882
 and: https://svnweb.freebsd.org/changeset/ports/431796

It looks like some of the gcc ports were not updated for this issue.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: devel/arm-none-eabi-gcc fails to build on 11-stable

[Dimitry Andric]

On 14 Mar 2018, at 14:46, tech-lists  wrote:
> 
> context:
> Working Copy Root Path: /usr/ports
> URL: https://svn.freebsd.org/ports/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 464450
> 
> $ uname -KU
> 1101509 1101509
> 
> devel/arm-none-eabi-gcc fails to build:
> 
> gmake[2]: Entering directory
> '/usr/ports/devel/arm-none-eabi-gcc/work/.build/gcc'
> c++ -c   -fbracket-depth=512 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE
> -fno-strict-aliasing -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
> -I/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc
> -I/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/build
> -I/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/../include
> -I/usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/../libcpp/include
> -DLIBICONV_PLUG \
>   -o build/genpreds.o
> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/genpreds.c
> c++: warning: treating 'c' input as 'c++' when in C++ mode, this
> behavior is deprecated [-Wdeprecated]
> In file included from
> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/genpreds.c:25:
> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/coretypes.h:62:1:
> warning: class 'rtx_def' was previously declared as a struct
> [-Wmismatched-tags]
> class rtx_def;
> ^
> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/coretypes.h:55:8:
> note: previous use is here
> struct rtx_def;
>   ^
> In file included from
> /usr/ports/devel/arm-none-eabi-gcc/work/gcc-6.3.0/gcc/genpreds.c:26:
> In file included from ./tm.h:17:
> ./options.h:5327:3: error: redefinition of enumerator 'OPT_C'
>  OPT_C = 127,   /* -C */
>  ^

Try building the port with LANG=C in your environment.  If I recall
correctly, this was some problem with sed in combination with non-C
language settings.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: openldap-server exit on signal 6 on 11.1 (and not in 10.3)

[Dimitry Andric]

On 9 Feb 2018, at 09:33, joris dedieu  wrote:
> 
> Dear porters,
> 
> While moving from 10.3 to 11.1, I get an issue on openldap execution.
> slapd dies (pid 29087 (slapd), uid 389: exited on signal 6) on some
> complex but reproducible operations.
> 
> We worked around this bug by returning less elements from the request.
> While my dear colleges are trying to write a script to reproduce the
> issue, I investigate system side.
> 
> 
> In /var/log/messages, I got slapd[4909]: stack overflow detected; terminated
> 
> The only trace I get
> 
> #0  0x000801f7a71a in kill () from /lib/libc.so.7
> #1  0x000801f7a6d0 in __stack_chk_fail () from /lib/libc.so.7
> #2  0x000801f7a640 in __stack_chk_fail () from /lib/libc.so.7
> #3  0x004466e6 in do_modify ()
> #4  0x004308d5 in connection_assign_nextid ()
> #5  0x004300dd in connection_read_activate ()
> #6  0x000800956ffa in ldap_pvt_thread_pool_submit () from
> /usr/local/lib/libldap_r-2.4.so.2
> #7  0x000801c71bc5 in pthread_create () from /lib/libthr.so.3
> #8  0x in ?? ()
> 
> I suspect it's relative to -fstack-protector-strong  which is the
> default since FreeBSD 11.0. Do you think I should rebuild all the
> world this opion ?
> 
> I also thought on fdatasync
> 
> .if ${OSVERSION} < 1101000
> CFLAGS+=-DMDB_DSYNC=O_SYNC -Dfdatasync=fsync
> .endif
> 
> I'm currently investigating on this changes.
> 
> The issue disappear when slapd is compiled with debugging symbols
> (WITH_DEBUG=YES). As far as I understand, this only cause -g flag to
> be added to CFLAGS. Does WITH_DEBUG also disable some compiler
> optimization  ?

Yes, WITH_DEBUG unfortunately removes all -O options from the compiler
flags, making it sometimes hard to debug, if any crashes disappear. :)

Try applying the following patch to your ports tree, and rebuilding the port:

Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk  (revision 461038)
+++ Mk/bsd.port.mk  (working copy)
@@ -1743,7 +1743,7 @@ MAKE_ENV+=DONTSTRIP=yes
 STRIP_CMD= ${TRUE}
 .endif
 DEBUG_FLAGS?=  -g
-CFLAGS:=   ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+CFLAGS:=   ${CFLAGS} ${DEBUG_FLAGS}
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=   ${INSTALL_TARGET:S/^install-strip$/install/g}
 .endif

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: CLANG6, java/openjdk[7|8] compiler error: atomic.inline.hpp:70 error: unknown token in expression __asm__ volatile

[Dimitry Andric]

On 17 Jan 2018, at 12:01, O. Hartmann  wrote:
> 
> On recent CURRENT (FreeBSD 12.0-CURRENT #0 r328002: Mon Jan 15 15:28:18 CET
> 2018 amd64) both ports java/openjdk7 and java/openjdk8 fail to compile with
> devel/openjdk8's error as follows:
> 
> 
> [...]
> In file included
> from 
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/share/vm/runtime/atomic.inline.hpp:70:
>  
> /usr/ports/java/openjdk8/work/openjdk/hotspot/src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp:95:21:
> error: unknown token in expression __asm__ volatile (LOCK_IF_MP(%4) "cmpxchgl
> %1,(%3)"

I had the idea this was worked around already, but I am planning on
committing an upstream fix for this very soon.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: atomic in i386 Current after CLANG 6 upgrade

[Dimitry Andric]

On 15 Jan 2018, at 11:43, Luca Pizzamiglio  wrote:
> 
> I've already received a couple of messages from pkg-fallout about build
> failure on head-i386-default [1] [2] both pointing to the same errors,
> about missing intrinsic symbols related to __atomic_*
> 
> The clang documentation about C11 atomic builtins [3] stats that __atomic_*
> are GCC extension and Clang provides them.
> 
> It seems to me that this specific GCC-compatible builtin are enabled on
> amd64, but not on i386.
> Is there a way to enable GCC compatible __atomic_ builtin also on i386?
> Or should I provide patches to adopt _c11_atomic_* instead of __atomic_*
> for every ports that need it ?

There is some strangeness going on with an upstream bug fix [1], which
has the unintended side effect of sometimes emitting libcalls to
__atomic functions that we do not have on i386.  I've commented on the
upstream bug report, but I do not know an easy workaround at this
point.

-Dimitry

[1] https://bugs.llvm.org/show_bug.cgi?id=34347



signature.asc
Description: Message signed with OpenPGP

Re: Firefox doesn't build...

[Dimitry Andric]

On 10 Nov 2017, at 22:43, Patrick Dorion  wrote:
> 
> ... on amd-64.
> 
> simd doesn't build: sse2 not found in x86.  i tried a bunch of options, 
> didn't work.

See https://bugs.freebsd.org/223415.  For now, rebuild lang/rust without the 
LLVM_PORT option.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: collectd5 pkg upgrade pulls in 72 new dependencies?

[Dimitry Andric]

On 5 Oct 2017, at 18:06, Pete Wright  wrote:
> 
> hey there - i was doing usual maintaince on my systems today and noticed that 
> when upgrading the collectd5 pkg it pulls in 72 new dependencies, mostly xorg 
> related.  here's a gist of the upgrade command exhibiting this.  the platform 
> 11.1-RELEASE:
> 
> https://gist.github.com/nomadlogic/53e81ba377a4a475351c3b8309be7598
> 
> is this expected?  maybe i missed a heads up email to this list?

From which version did you upgrade?  The most recent change to the port
is that the DEBUG, GCRYPT and PING options were enabled by default,
here:

https://svnweb.freebsd.org/ports?view=revision=449798

However, the only dependencies added because of it are libgcrypt and
liboping, which should not really be dependent on any xorg stuff.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: compler warnings in ports not supported in gcc 4.2.1 (stable/10)

[Dimitry Andric]

On 23 Sep 2017, at 23:42, Julian Elischer  wrote:
> 
> Trying to compile the emulators/open-vm-tools-nox11 port
> 
> but I end up dying with:
> 
> libtool: compile:  cc -DPACKAGE_NAME=\"open-vm-tools\" 
> -DPACKAGE_TARNAME=\"open-vm-tools\" -DPACKAGE_VERSION=\"10.1.5\" 
> "-DPACKAGE_STRING=\"open-vm-tools 10.1.5\"" 
> -DPACKAGE_BUGREPORT=\"open-vm-tools-de...@lists.sourceforge.net\" 
> -DPACKAGE_URL=\"\" -DPACKAGE=\"open-vm-tools\" -DVERSION=\"10.1.5\" 
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 
> -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" 
> -DX_DISPLAY_MISSING=1 -DHAVE_DLOPEN=1 -DNO_PROCPS=1 -DNO_DNET=1 
> -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_WCHAR_H=1 
> -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_USER_H=1 -DHAVE__BOOL=1 
> -DHAVE_STDBOOL_H=1 -DHAVE_STRUCT_STAT_ST_RDEV=1 -DTIME_WITH_SYS_TIME=1 
> -DNO_XSM=1 -DNO_XCOMPOSITE=1 -DNO_MULTIMON=1 -I. 
> -I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include
>  
> -I/usr/ports/emulators/open-vm-tools-nox11/work/open-vm-tools-stable-10.1.5/open-vm-tools/lib/include
>  -Wno-deprecated-declarations -isystem /usr/local/include -DUSING_AUTOCONF=1 
> -DOPEN_VM_TOOLS -DNO_ICU -DVMX86_TOOLS -O2 -pipe -DPANZURA_DEV -DPZ_FBSD_10 
> -isystem /usr/local/include -fno-strict-aliasing -Wall -Werror 
> -Wno-unused-function -Wno-address-of-packed-member 
> -Wno-unknown-warning-option -Wno-unused -MT nicinfo_xdr.lo -MD -MP -MF 
> .deps/nicinfo_xdr.Tpo -c nicinfo_xdr.c  -fPIC -DPIC -o .libs/nicinfo_xdr.o
> cc1: error: unrecognized command line option "-Wno-address-of-packed-member"
> cc1: error: unrecognized command line option "-Wno-unknown-warning-option"
> *** [nicinfo_xdr.lo] Error code 1
> 
> 
> the system in question is compiled with gcc
> 
> 
> is there a supported way of making the port not set those flags on each cc1 
> command?

This appears to have been broken by r444773.  Try replacing
emulators/open-vm-tools/files/patch-configure.ac with the attached file.

-Dimitry


patch-configure.ac
Description: Binary data


signature.asc
Description: Message signed with OpenPGP

Re: Extra Clang Tools

[Dimitry Andric]

On 16 Sep 2017, at 04:29, blubee blubeeme  wrote:
> 
> FreeBSD switched to clang as it's compiler some time ago; was clang extra
> tools: http://clang.llvm.org/extra/index.html ever ported over?
> 
> If yes, where is it located?

Those tools (clang-tidy, clang-include-fixer, etc) are not available in
the base system.  Install one of the devel/llvm ports, and enable the
EXTRAS option.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Failed to build a port (tempus) on i386

[Dimitry Andric]

On 11 Sep 2017, at 22:39, L.Bartoletti  wrote:
> 
> I'm trying to port the tempus  framework on 
> FreeBSD. All packages are nearly ready except the core for i386...
> 
> I come to you because I don't understand the difference of the logs between 
> i386 and amd64. I suspect some clang errors and maybe boost, but not sure of 
> myself.
> 
> Tempus_core requires c++11. So, I have tested with c++11-lang and c++11-lib 
> without success.

As far as I can see from the logs, your program still needs to add
-std=c++11 (or -std=gnu++11) to its compilation flags.  Either the
program's configure or cmake scripts should do this, or you could use
USE_CXXSTD=c++11.


> I find a (dirty) solution for 10amd64: force the compiler to be clang40. 
> Unfortunately, it doesn't work on i386...

Not sure why that would be needed. You should be able to compile C++11
code on 10.x just fine.


> All my tests are on my gitlab 
> , 
> containing ports and logs.

These logs contain errors caused by -std=c++11 missing from the
compilation flags.  Add that flag to get rid of them.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: [poudriere] poudriere non-responsive, zombie sh

[Dimitry Andric]

On 14 Aug 2017, at 08:19, O. Hartmann  wrote:
> 
> Running FreeBSD 12.0-CURRENT #87 r322472: Sun Aug 13 21:59:36 CEST 2017 amd64
> with jail of the same revision, lately the poudriere build system started to
> get inresponsive when hitting Ctrl-C or, very often, starts to stop when
> showing up which package is deleted or has to be rebuild due to changed
> dependencies.
...
> Seems therer is an issue lately introduced.

Can you please check whether the problem is caused by this recent commit
to security/sudo, which changes the signal handling:

https://svnweb.freebsd.org/ports?view=revision=447784

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Clang5 crashing on RPI2 compiling gnome3

[Dimitry Andric]

On 29 Jul 2017, at 03:09, bob prohaska  wrote:
> 
> Attempts to compile gnome3 on an RPI2 have run hard aground on
> 
> :57:6: note: expanded from here
> Assertion failed: (0 <= N && N < static_cast(m_byteToColumn.size())), 
> function byteToContainingColumn, file 
> /usr/src/contrib/llvm/tools/clang/lib/Frontend/TextDiagnostic.cpp, line 281.

Yes, this is a relatively recent regression, see 
https://bugs.llvm.org/show_bug.cgi?id=33902


> Is there a workaround?

At the moment I don't know any.  I haven't had time to look into the bug itself.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: ext/atomicity.h bits/c++config.h

[Dimitry Andric]

On 13 Jul 2017, at 20:50, Otacílio  wrote:
> 
> I'm trying to make a port for personal use of the rmtp library. However I'm 
> having some problems that I can not solve with just the help of google. Among 
> other things, the compilation is breaking at this point
> 
> In file included from 
> /usr/ports/science/mrpt/work/.build/libs/base/cotire/mrpt-base_CXX_prefix.hxx:4:
> In file included from 
> /usr/ports/science/mrpt/work/.build/libs/base/cotire/mrpt-base_CXX_prefix.cxx:4:
> In file included from 
> /usr/ports/science/mrpt/work/mrpt-752b211/libs/base/src/base-precomp.h:17:
> In file included from 
> /usr/ports/science/mrpt/work/mrpt-752b211/libs/base/include/mrpt/utils/CObject.h:17:
> In file included from 
> /usr/ports/science/mrpt/work/mrpt-752b211/libs/base/include/mrpt/otherlibs/stlplus/smart_ptr.hpp:49:
> /usr/ports/science/mrpt/work/mrpt-752b211/libs/base/include/mrpt/synch/atomic_incr.h:20:12:
>  fatal error: 'ext / atomicity.h' file not found
> #include 

This header is a GNU libstdc++ specific extension, e.g. it is non-portable.  If 
the program insists on having this header, you should probably use one of the 
gcc ports to build it.  In most cases, the program can be changed to use a 
portable header instead.


> I have found this library in /usr/src/contrib/libstdc ++/include and I do not 
> know the correct way to include it in the project because I expected to find 
> it in /usr/include or /usr/local/include. I even added this line in the 
> configuration: -I/usr/src/contrib/libstdc++/include but now went on to 
> complain that this other head file is missing
> 
> /usr/src/contrib/libstdc++/include/ext/atomicity.h:38:10: fatal error: 
> 'bits/c++config.h' file not found

You can't do that, most headers under /usr/src are not suitable for direct 
inclusion, they have to be installed in the right locations.  Again, try using 
one of the gcc ports instead, they will automatically find their own libstdc++ 
headers (usually under /usr/local/lib/gccX/include/c++/ext).

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: print/texinfo build, and httpd dying?

[Dimitry Andric]

On 2 Jul 2017, at 19:25, Larry Rosenman  wrote:
...
> [12:19]
> I also can’t get my httpd up it sigsegv’s in parsing it’s config
> 
> [12:19]
> driving me nuts today
> 
> [12:20]
> borg.lerctr.org 
> /usr/local/poudriere/data/logs/bulk/live-host-ports/2017-07-02_12h16m20s/logs/errors
>  $ uname -aKU
> FreeBSD borg.lerctr.org 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r320573: Sun Jul 
>  2 10:50:05 CDT 2017 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER  
> amd64 1200037 1200037
> borg.lerctr.org 
> /usr/local/poudriere/data/logs/bulk/live-host-ports/2017-07-02_12h16m20s/logs/errors
>  $
> 
> [12:21]
> borg.lerctr.org / $ gdb -c httpd.core /usr/local/sbin/httpd
> GNU gdb (GDB) 7.12.1 [GDB v7.12.1 for FreeBSD]
> Copyright (C) 2017 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type “show copying”
> and “show warranty” for details.
> This GDB was configured as “x86_64-portbld-freebsd12.0”.
> Type “show configuration” for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type “help”.
> Type “apropos word” to search for commands related to “word”...
> Reading symbols from /usr/local/sbin/httpd...(no debugging symbols 
> found)...done.
> [New LWP 101514]
> Core was generated by `/usr/local/sbin/httpd -DNOHTTPACCEPT -t’.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x000801d09b90 in strcmp () from /lib/libc.so.7
> (gdb) bt
> #0  0x000801d09b90 in strcmp () from /lib/libc.so.7
> #1  0x00457d9a in process_resource_config_fnmatch ()
> #2  0x00457d2f in process_resource_config_fnmatch ()
> #3  0x00457d2f in process_resource_config_fnmatch ()
> #4  0x00457d2f in process_resource_config_fnmatch ()
> #5  0x00457d2f in process_resource_config_fnmatch ()
> #6  0x00457d2f in process_resource_config_fnmatch ()
> #7  0x00457a69 in ap_process_fnmatch_configs ()
> #8  0x00448eb0 in include_config ()
> #9  0x00459ac8 in invoke_cmd ()
> #10 0x00456cda in ap_build_config_sub ()
> #11 0x004571ab in ap_build_config ()
> #12 0x004578d9 in ap_process_resource_config ()
> #13 0x00458d81 in ap_read_config ()
> #14 0x00430c8d in main ()

Assuming this is about www/apache24, it works fine for me.  Maybe this
is something specific to your configuration.  Does it start successfully
using the stock configuration?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: print/texinfo build, and httpd dying?

[Dimitry Andric]

On 2 Jul 2017, at 19:25, Larry Rosenman  wrote:
> 
> Upgraded my -CURRENT system today, and httpd dies on a SIGSEGV, and I can't 
> build
> print/texinfo.
> 
> anyone else having issues building texinfo on -CURRENT?
> panic: bad free, ->next->prev=80509aaa0, header=80509aaa0, 
> ->prev->next=a5a5a5a5a5a50020 at ../tp/Texinfo/Parser.pm line 3907.
> panic: bad free, ->next->prev=5a5a5a5a5a5a5a5a, header=80509a9b0, 
> ->prev->next=80509a9b0 during global destruction.
> gmake[4]: *** [Makefile:1297: info-stnd.info] Error 25
> gmake[4]: *** Waiting for unfinished jobs
> Assertion failed: (header->next->prev == header), function 
> Perl_safesysrealloc, file util.c, line 243.
> Abort trap (core dumped)

For texinfo, please try the patch I added to https://bugs.freebsd.org/220447

I haven't looked at httpd.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: best way to handle GCC version detection

[Dimitry Andric]

On 27 Jun 2017, at 17:39, Aryeh Friedman  wrote:
> 
> I have port I maintain that compiles fine under GCC 5 (or lower) but barfs
> on GCC 6.   A small modification will make it compile under 6 but the very
> same modification makes it incompatible with 5.   What is the best way to
> handle this and still allow USE_GCC=any ?

Something like:

#if __GNUC__ <= 5
   ...foo...
#else
   ...bar...
#endif

could maybe work?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: ERRATA: 12.0-CURRENT binaries 'stat' errors.

[Dimitry Andric]

On 14 Jun 2017, at 13:51, Jeffrey Bouquet  wrote:
> 
> ne
> /usr/local/bin/ne: Undefined symbol "stat"
> ktrace -di ne
> /usr/local/bin/ne: Undefined symbol "stat"

Be sure to exactly follow the procedure mentioned in /usr/src/UPDATING
entry 20170523.  My guess is that you do not have COMPAT_FREEBSD11 in
your kernel configuration.  If so, add that option, then rebuild and
reinstall your kernel.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: How to stop ports recompiling gcc, llvm, etc.?

[Dimitry Andric]

On 13 Jun 2017, at 15:51, Rastko P  wrote:
> 
> I think my machine will die from severe dehydration if every other port
> keeps recompiling compilers.
> 
> The last make for the "documentation translation" port took 6 hours or
> more.  What's that in fan oil costs?
> 
> 
> How to prevent this?

Install binary packages.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Looking for python-pecan

[Dimitry Andric]

On 12 Jun 2017, at 13:29, Willem Jan Withagen  wrote:
> 
> For one the Ceph port I'm doing I'm going to need python-pecan in het
> close future.
> 
> Not sure how this works with python-modules since it is something that
> is only used by the ceph-ports. But my guess is that I won't be
> able/allowed to just have a post execute like:
> 
>   ping install python-pecan.

Normally you would use pip, ping is something entirely different. :)

Here is a patch to add a devel/py-pecan port, plus one of its
dependencies that is not yet in the ports tree, devel/py-logutils.

Tested only very lightly, please take care.

-Dimitry


add-devel_py-pecan-and-deps.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP

Re: Unable to upgrade from Samba43 to Samba44 or Samba45

[Dimitry Andric]

On 10 Jun 2017, at 06:56, Stefan Esser <s...@freebsd.org> wrote:
> 
> Am 08.06.17 um 21:15 schrieb Dimitry Andric:
>> On 8 Jun 2017, at 20:35, Mark Knight <li...@knigma.org> wrote:
>>> 
>>> On 08/06/2017 18:35, Dimitry Andric wrote:
>>>> I'm guessing that it is confused by an existing samba installation.  Try
>>>> removing all other samba installations before attempting to build this
>>>> port.
>>> 
>>> Having followed an off-list suggestion to create a package (thanks) as a 
>>> backup, I removed samba43 and established that your "guess" was right. 
>>> Thank you!
>>> 
>>> Presumably this implies a bug in the port?
>> 
>> Not really, more a deficiency in portmaster.  The port itself is marked
>> as conflicting with any other samba port:
>> 
>> CONFLICTS?= *samba3[2-6]-3.* samba4-4.0.* samba4[1-356]-4.* 
>> p5-Parse-Pidl-4.*
>> 
>> E.g., you should normally not be able to build it when samba43 is
>> installed.  Probably, portmaster is overriding this safety belt somehow.
> 
> I have always understood CONFLICTS to indicate, that some port
> can not be *installed* at the same time as some of the ports listed
> as conflicting.

In fact, you cannot even download the port sources in such a case, e.g:

$ make -C /usr/ports/net/samba44 fetch

===>  samba44-4.4.14 conflicts with installed package(s):
  samba46-4.6.4

  They install files into the same place.
  You may want to stop build with Ctrl + C.


> Building such a port while a conflicting version is installed, is
> possible most of the time. If such a build fails, it is most ofter
> due to the build preferring the already installed headers over those
> provided with the new version (i.e. a wrong ordering of include
> paths).

Yes, this is apparently one of the reasons lang/rust even conflicts with
*itself*.  There seems to be something very broken in its build process,
so that it cannot build correctly if any of its files are installed on
the system.

That said, things like this could probably be solved by adding separate
CONFLICTS_BUILD, CONFLICT_FETCH and so on, but it makes it all rather
complicated.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Unable to upgrade from Samba43 to Samba44 or Samba45

[Dimitry Andric]

On 8 Jun 2017, at 20:35, Mark Knight <li...@knigma.org> wrote:
> 
> On 08/06/2017 18:35, Dimitry Andric wrote:
>> I'm guessing that it is confused by an existing samba installation.  Try
>> removing all other samba installations before attempting to build this
>> port.
> 
> Having followed an off-list suggestion to create a package (thanks) as a 
> backup, I removed samba43 and established that your "guess" was right. Thank 
> you!
> 
> Presumably this implies a bug in the port?

Not really, more a deficiency in portmaster.  The port itself is marked
as conflicting with any other samba port:

CONFLICTS?= *samba3[2-6]-3.* samba4-4.0.* samba4[1-356]-4.* 
p5-Parse-Pidl-4.*

E.g., you should normally not be able to build it when samba43 is
installed.  Probably, portmaster is overriding this safety belt somehow.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Unable to upgrade from Samba43 to Samba44 or Samba45

[Dimitry Andric]

On 8 Jun 2017, at 18:13, Mark Knight  wrote:
> 
> When attempting to upgrade to Samba44 or Samba45 (as required by the removal 
> of Samba43 yesterday), I get this error:
> 
> /usr/ports/net/samba44/work/samba-4.4.14/bin/../source4/libnet/libnet_passwd.c:85:
>  undefined reference to `arcfour_crypt'
> 
> I wondered if this was an OpenSSL issue, but then it looks like arcfour_crypt 
> is part of Samba so I'm a little confused.
> 
> Complete build log, make.conf and options here:
> 
> http://www.knigma.org/scratch/samba44.log
> 
> Any advice please? Thanks in advance!!

I'm guessing that it is confused by an existing samba installation.  Try
removing all other samba installations before attempting to build this
port.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: samba 44 and bind 911

[Dimitry Andric]

On 1 Jun 2017, at 11:55, Xavier  wrote:
> 
> I hava a build problem while upgrading samba44 :
> 
> [root@numenor ~]# portupgrade -v samba44
> [... building...]
> ===>  Staging for samba44-4.4.14
> ===>   samba44-4.4.14 depends on package: libarchive>=3.1.2 - found
> ===>   samba44-4.4.14 depends on package: py27-dnspython>=1.9.4 - found
> ===>   samba44-4.4.14 depends on package: py27-iso8601>=0.1.11 - found
> ===>   samba44-4.4.14 depends on package: talloc>=2.1.6 - found
> ===>   samba44-4.4.14 depends on package: tevent>=0.9.28 - found
> ===>   samba44-4.4.14 depends on package: tdb>=1.3.8 - found
> ===>   samba44-4.4.14 depends on package: ldb>=1.1.26 - found
> ===>   samba44-4.4.14 depends on package: bind910>=9.10.0.0 - not found
> 
> ===>  bind910-9.10.5 conflicts with installed package(s):
>  bind911-9.11.1
> 
> It seems that samba44 requires bind 910 while bind 911 doesent meet the
> requisite bind910>=9.10.0.0
> 
> Is there another workaround than to downgrade bind911 to 910 ?

Run "make config" in the net/samba44 directory, and select "Use bind911
as AD DC DNS server frontend".

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Firefox (and other Mozilla products) after ino64

[Dimitry Andric]

Hi,

Due to the recent ino64 update in 12.0-CURRENT, there have been some
reports by Firefox port users about crashes.  While I personally have
not experienced these crashes, as I immediately rebuilt all my ports
from scratch after the ino64 update, I think can explain why the
following combination is very likely to have problems:

* kernel+world after ino64
* www/firefox package from before ino64

It is because Firefox's JavaScript engine is doing tricks to get at libc
structures and functions (via an FFI mechanism), and several structure
layouts and offsets are hardcoded into its engine at build time.

For instance, here is the place where the engine determines the offset
of struct dirent's d_name field:

  
https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l648

Further down in the file, several offsets of fields in struct stats are
similarly determined:

  
https://hg.mozilla.org/mozilla-central/file/tip/dom/system/OSFileConstants.cpp#l677

Now, since ino64 changed quite a number of structure layouts, including
struct dirent, struct stat, and others, such offsets determined in the
past will no longer be valid!

It is pretty likely that Firefox will attempt to access these fields,
finding bogus values, or simply reading invalid memory, and crashing
because of this.  Or at the least, the behavior will be unstable.

This also applies to other Mozilla products, such as Thunderbird,
SeaMonkey, and so on.  These should all be rebuilt from scratch under
ino64.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: gcc5 not building on 11-0-RELEASE

[Dimitry Andric]

On 30 May 2017, at 19:19, Fernando Herrero Carrón  wrote:
> 
> Hi everyone:
> 
> I am trying to build lang/gcc5 using Poudriere from ports tree just updated
> a couple of hours ago.
> 
> The port fails to link with:
> 
> /usr/local/bin/ld:
> /wrkdirs/usr/ports/lang/gcc5/work/.build/./gcc/liblto_plugin.so: error
> loading plugin: Service unavailable

This is usually the message you get when static executables attempt to
use dlopen().  Did you manage to link /usr/local/bin/ld as a static
executable?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Any hope of compiling firefox port on ARM?

[Dimitry Andric]

On 19 Apr 2017, at 00:17, bob prohaska  wrote:
> 
> On Tue, Apr 18, 2017 at 09:43:23PM +0200, Jan Beich wrote:
>> 
>> See bug 211069 which was duped against bug 203989 that triggered a
>> different assertion. The above error did show up on armv6 buildbot[1]
>> but nowadays is blocked by other ports.
>> 
> What is meant by the term "blocked by other ports"? The error still
> comes up with firefox and -current as of yesterday.

How is that even possible?  I committed the fix on Oct 12, 2016:

  https://svnweb.freebsd.org/changeset/ports/423893

then merged it to the 2016Q4 quarterly branch on Oct 14, 2016:

  https://svnweb.freebsd.org/changeset/ports/423974

Maybe you are seeing a different problem altogether?  Or your ports tree
has no been updated?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Any hope of compiling firefox port on ARM?

[Dimitry Andric]

On 18 Apr 2017, at 21:43, Jan Beich <jbe...@freebsd.org> wrote:
> 
> Dimitry Andric <d...@freebsd.org> writes:
> 
>> On 18 Apr 2017, at 20:47, bob prohaska <f...@www.zefox.net> wrote:
>> 
>>> 
>>> For some time (years?) firefox compiles have failed with an error message
>>> along the lines of
>>> 
>>> Assertion failed: (isReg() && "This is not a register operand!"),
>>> function getReg, file
>>> /usr/src/contrib/llvm/include/llvm/MC/MCInst.h, line 64.
>>> c++: error: unable to execute command: Abort trap (core dumped)
>>> c++: error: clang frontend command failed due to signal (use -v to see 
>>> invocation)
>>> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
>>> 4.0.0)
>>> Target: armv6--freebsd12.0-gnueabihf
>>> Thread model: posix
>>> InstalledDir: /usr/bin
>>> c++: note: diagnostic msg: PLEASE submit a bug report to
>>> https://bugs.freebsd.org/submit/ and include the crash backtrace,
>>> preprocessed source, and associated run script.
>>> 
>>> Is there any hope of a fix, whether to clang or firefox?
>> 
>> Have you tried doing what it asks, e.g. file a bug report? :)
>> 
>> I can find no such bug report in our tracker.  Please submit a bug with
>> the two files (.sh and .cpp) it generates in /tmp.
> 
> See bug 211069 which was duped against bug 203989 that triggered a
> different assertion.

Hmm, annoying that bugzilla doesn't find those bugs, if you search for
any keyword in the error message.  So this bug has been solved for 6
months now, in any case.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Any hope of compiling firefox port on ARM?

[Dimitry Andric]

On 18 Apr 2017, at 20:47, bob prohaska  wrote:
> 
> For some time (years?) firefox compiles have failed with an error message
> along the lines of
> 
> Assertion failed: (isReg() && "This is not a register operand!"), function 
> getReg, file /usr/src/contrib/llvm/include/llvm/MC/MCInst.h, line 64.
> c++: error: unable to execute command: Abort trap (core dumped)
> c++: error: clang frontend command failed due to signal (use -v to see 
> invocation)
> FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 
> 4.0.0)
> Target: armv6--freebsd12.0-gnueabihf
> Thread model: posix
> InstalledDir: /usr/bin
> c++: note: diagnostic msg: PLEASE submit a bug report to 
> https://bugs.freebsd.org/submit/ and include the crash backtrace, 
> preprocessed source, and associated run script.
> 
> Is there any hope of a fix, whether to clang or firefox?

Have you tried doing what it asks, e.g. file a bug report? :)

I can find no such bug report in our tracker.  Please submit a bug with
the two files (.sh and .cpp) it generates in /tmp.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Building math/fftw3 on armv6

[Dimitry Andric]

On 8 Apr 2017, at 23:09, Jonathan Chen  wrote:
> 
> I'm attempting to build math/fftw3 on 11-STABLE/armv6, r315896. I'm
> getting a build failure towards the end when building its internal
> tests.
> 
> [...]
> Making all in tests
> gmake[3]: Entering directory
> '/tmp/usr/ports/math/fftw3/work/fftw-3.3.6-pl2/tests'
> cc -DHAVE_CONFIG_H -I. -I..  -I../kernel -I../libbench2 -I../dft
> -I../rdft -I../reodft -I../threads -I../api   -D_THREAD_SAFE -pthread
> -O -pipe  -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer -MT
> bench-bench.o -MD -MP -MF .deps/bench-bench.Tpo -c -o bench-bench.o
> `test -f 'bench.c' || echo './'`bench.c
> cc -DHAVE_CONFIG_H -I. -I..  -I../kernel -I../libbench2 -I../dft
> -I../rdft -I../reodft -I../threads -I../api   -D_THREAD_SAFE -pthread
> -O -pipe  -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer -MT
> bench-hook.o -MD -MP -MF .deps/bench-hook.Tpo -c -o bench-hook.o `test
> -f 'hook.c' || echo './'`hook.c
> cc -DHAVE_CONFIG_H -I. -I..  -I../kernel -I../libbench2 -I../dft
> -I../rdft -I../reodft -I../threads -I../api   -D_THREAD_SAFE -pthread
> -O -pipe  -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer -MT
> bench-fftw-bench.o -MD -MP -MF .deps/bench-fftw-bench.Tpo -c -o
> bench-fftw-bench.o `test -f 'fftw-bench.c' || echo './'`fftw-bench.c
> mv -f .deps/bench-fftw-bench.Tpo .deps/bench-fftw-bench.Po
> mv -f .deps/bench-hook.Tpo .deps/bench-hook.Po
> mv -f .deps/bench-bench.Tpo .deps/bench-bench.Po
> /bin/sh ../libtool  --tag=CC   --mode=link cc -D_THREAD_SAFE -pthread
> -O -pipe  -O3 -ffast-math -fstrict-aliasing -fomit-frame-pointer   -o
> bench bench-bench.o bench-hook.o bench-fftw-bench.o
> ../threads/libfftw3_threads.la ../libfftw3.la ../libbench2/libbench2.a
> -lm
> libtool: link: cc -D_THREAD_SAFE -pthread -O -pipe -O3 -ffast-math
> -fstrict-aliasing -fomit-frame-pointer -o .libs/bench bench-bench.o
> bench-hook.o bench-fftw-bench.o  ../threads/.libs/libfftw3_threads.so
> ../.libs/libfftw3.so ../libbench2/libbench2.a -lm -pthread -Wl,-rpath
> -Wl,/usr/local/lib
> ../libbench2/libbench2.a(verify-lib.o): In function `aphase_shift':
> verify-lib.c:(.text+0x578): undefined reference to `sincos'
> ../libbench2/libbench2.a(verify-lib.o): In function `tf_shift':
> verify-lib.c:(.text+0x1380): undefined reference to `sincos'
> verify-lib.c:(.text+0x1574): undefined reference to `sincos'
> verify-lib.c:(.text+0x1834): undefined reference to `sincos'
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> gmake[3]: *** [Makefile:400: bench] Error 1
> gmake[3]: Leaving directory
> '/tmp/usr/ports/math/fftw3/work/fftw-3.3.6-pl2/tests'
> gmake[2]: *** [Makefile:684: all-recursive] Error 1
> gmake[2]: Leaving directory '/tmp/usr/ports/math/fftw3/work/fftw-3.3.6-pl2'
> gmake[1]: *** [Makefile:549: all] Error 2
> gmake[1]: Leaving directory '/tmp/usr/ports/math/fftw3/work/fftw-3.3.6-pl2'
> 
> The build *does* succeed for 11-STABLE/amd64, r315896. It appears to
> be an armv6 specific issue?

See https://bugs.freebsd.org/215977 for the full story.

-Dimitry




signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 30 Mar 2017, at 19:55, Brooks Davis <bro...@freebsd.org> wrote:
> 
> On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote:
...
>> 
>> As said, this is because of WITH_DEBUG.  Don't use that for the llvm
>> ports, for now.  It will also allow you to build them with much less RAM
>> in the machine: especially linking can take multiple GB when debuginfo
>> is enabled, and optimization is off.
> 
> I'm looking into improving WITH_DEBUG.

I stole the following method from graphics/darktable:

Index: devel/llvm40/Makefile
===
--- devel/llvm40/Makefile   (revision 436685)
+++ devel/llvm40/Makefile   (working copy)
@@ -236,6 +236,11 @@ NOT_FOR_ARCH=  ia64

 .include 

+.if defined(WITH_DEBUG)
+CMAKE_BUILD_TYPE=  RelWithDebInfo
+STRIP=
+.endif
+
 _CRTLIBDIR=
${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd
 .if ${ARCH} == "amd64"
 _COMPILER_RT_LIBS= \

This appears to work for me.


> P.S. Somewhat off topice, but related.  FAIR WARNING: the days of
> self-hosted 32-bit systems are numbered.  Switching to lld from our
> ancient BFD linker will probably buy us some time, but I'd be surprised
> if you will be able to build LLVM+CLANG with a 2GB address space in 5
> years.  The sooner people make their peace with this, the better.

Yes, with that above RelWithDebInfo change, GNU ld tends to use ~5G of
memory to link the larger llvm executables, so that is definitely beyond
i386, even if you run it in a jail on an amd64 host.

And if you would want to use link time optimization, the requirements
will increase even more...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 30 Mar 2017, at 19:06, Alexey Dokuchaev <da...@freebsd.org> wrote:
> 
> On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote:
>>> ...
>>> Also interesting was:
>>> 
>>> Installed packages to be REMOVED:
>>> llvm40-4.0.0.r4
>>> 
>>> Number of packages to be removed: 1
>>> 
>>> The operation will free 49 GiB.
>> 
>> Yes, this is big.  But there is no real need to build the llvm ports
>> with debug information, unless you want to hack on llvm itself.
> 
> Cc'ing jmd@ and rezny@.
> 
> I've been watching increasing size of our LLVM packages with increasing
> worry.  This is from my tinderbox cache:
> 
>  $ % env LANG=C ls -lh llvm3*
>  -rw-r--r--  1 root  wheel17M Jan 29  2016 llvm35-3.5.2_1.txz
>  -rw-r--r--  1 root  wheel18M Mar  7  2016 llvm36-3.6.2_2.txz
>  -rw-r--r--  1 root  wheel27M Feb 28 01:05 llvm37-3.7.1_4.txz
>  -rw-r--r--  1 root  wheel   207M Jan 19 18:20 llvm38-3.8.1_5.txz
>  -rw-r--r--  1 root  wheel   244M Mar 23 16:42 llvm39-3.9.1_2.txz
> 
> Dimitry, do you know what had causes such a huge bump in 37 -> 38?

Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY
parts, with separate ports for e.g. compiler-rt and other LLVM projects.

For llvm38 and later, the devel/llvmXY port contains almost *all*
upstream LLVM components, which are then selectable at port configure
time.  For instance, devel/llvm40 shows:

┌─── llvm40-4.0.0 ─┐
│ ┌──┐ │
│ │ [x] CLANGBuild clang │ │
│ │ [x] COMPILER_RT  Sanitizer libraries │ │
│ │ [x] DOCS Build and/or install documentation  │ │
│ │ [x] EXTRAS   Extra clang tools   │ │
│ │ [x] GOLD Build the LLVM Gold plugin for LTO  │ │
│ │ [x] LIT  Install lit and FileCheck test tools│ │
│ │ [x] LLD  Install lld, the LLVM linker│ │
│ │ [x] LLDB Install lldb, the LLVM debugger (ignored on 9.x)│ │
│ │ [x] OPENMP   Install libomp, the LLVM OpenMP runtime library │ │
│ └──┘ │
├──┤
│   <  OK  >   │
└──┘

If you want to reduce the size of the package, only select the part(s)
you need.  I think you can get by with just the CLANG option, for most
dependent ports.



> They take lots of time to build and package.  And given that llvm
> is indirect dependency of any X11-related port, it pessimises their
> build times as well (devel/libclc now requires devel/llvm40 after
> r437268).

The previous split looks pretty hard to maintain, so that is most likely
the reason for combining all components in one port after 3.8.
Unfortunately the side effect is that it is way less granular.

If we ever get infrastructure for generating multiple packages out of
one port, the devel/llvm* ports are very good candidates. :)


> With 49 GiB llvm40, I guess I won't be able to build-test post as my
> hardware would just not be capable enough.

As said, this is because of WITH_DEBUG.  Don't use that for the llvm
ports, for now.  It will also allow you to build them with much less RAM
in the machine: especially linking can take multiple GB when debuginfo
is enabled, and optimization is off.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 29 Mar 2017, at 17:53, Brooks Davis  wrote:
> 
> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
...
>> This is extreme enough that next time I synchronize
>> /usr/ports and it has a devel/llvm40 update I'll
>> likely rebuild devel/llvm40 without using WITH_DEBUG= .
>> I'm more concerned with the time it takes than with
>> the file system space involved.
> 
> In the case of LLVM, enabling debug builds does a LOT more than adding
> symbols.  It's much more like enabling WITNESS and INVARIANTS in your
> kernel, except that the performance of the resulting binary is much
> worse than a WITNESS kernel (more like 10x slowdown).
> 
> As Dimitry points out, these builds are of questionable value in ports
> so garbage collecting the knob might be the sensable thing to do.

I suggest that for the LLVM ports, the DEBUG option should set the
RelWithDebInfo build type for CMake.  That will give you binaries which
can produce good backtraces, and a fair chance at debugging, in a pinch.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 27 Mar 2017, at 23:11, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2017-Mar-27, at 5:53 AM, Dimitry Andric  wrote:
>> On 27 Mar 2017, at 12:25, Mark Millard  wrote:
>>> 
>>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric <d...@freebsd.org> wrote:
>>>> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote:
>> ...
>>>>> Installed packages to be REMOVED:
>>>>>   llvm40-4.0.0.r4
>>>>> 
>>>>> Number of packages to be removed: 1
>>>>> 
>>>>> The operation will free 49 GiB.
>>>> 
>>>> Yes, this is big.  But there is no real need to build the llvm ports
>>>> with debug information, unless you want to hack on llvm itself.  And
>>>> in that case, you are better served by a Subversion checkout or Git
>>>> clone from upstream instead.
>> ...
>>> Historically unless something extreme like this ends up
>>> involved I build everything using WITH_DEBUG=  or explicit
>>> -g's in order to have better information on any failure.
>> 
>> The problem with the ports implementation of WITH_DEBUG is that it
>> always disables all optimizations, without a possibility to override.
>> Which bloats the resulting object files, libraries and executables, and
>> especially so for large C++ projects such as LLVM.
>> 
>> I can recommend the following workaround.  If you want to build a port
>> with optimizations disabled, you can always pass -O0 in CFLAGS.
>> 
>> -Dimitry
>> 
>> Index: Mk/bsd.port.mk
>> ===
>> --- Mk/bsd.port.mk   (revision 436685)
>> +++ Mk/bsd.port.mk   (working copy)
>> @@ -1646,7 +1646,7 @@ MAKE_ENV+= DONTSTRIP=yes
>> STRIP_CMD=   ${TRUE}
>> .endif
>> DEBUG_FLAGS?=-g
>> -CFLAGS:=${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
>> +CFLAGS:=${CFLAGS} ${DEBUG_FLAGS}
>> .if defined(INSTALL_TARGET)
>> INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
>> .endif
> 
> Interesting. WITH_DEBUG's description in the file does not
> mention that stripping of optimization flags:
> 
> # WITH_DEBUG- If set, debugging flags are added to CFLAGS and the
> # binaries don't get stripped by INSTALL_PROGRAM or
> # INSTALL_LIB. Besides, individual ports might
> # add their specific to produce binaries for debugging
> # purposes. You can override the debug flags that are
> # passed to the compiler by setting DEBUG_FLAGS. It is
> # set to "-g" at default.
> 
> I'll probably give myself an override that I can specify in
> /etc/make.conf , such as:
> 
> # svnlite diff /usr/ports/Mk/bsd.port.mk
> Index: /usr/ports/Mk/bsd.port.mk
> ===
> --- /usr/ports/Mk/bsd.port.mk (revision 436747)
> +++ /usr/ports/Mk/bsd.port.mk (working copy)
> @@ -1646,7 +1646,11 @@
> STRIP_CMD=${TRUE}
> .endif
> DEBUG_FLAGS?= -g
> +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
> +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
> +.else
> CFLAGS:=  ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
> +.endif
> .if defined(INSTALL_TARGET)
> INSTALL_TARGET:=  ${INSTALL_TARGET:S/^install-strip$/install/g}
> .endif

Effectively, this gives some sort of support for three of CMake's build
types, e.g:
* Debug, which disables optimization, and obviously adds debuginfo
* Release, which optimizes for speed, and does not add debuginfo
* RelWithDebInfo, similar to Release but does add debuginfo

It would be nice if there was some way of directly utilizing these.  The
RelWithDebInfo target is very useful with the LLVM projects.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 27 Mar 2017, at 12:25, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric <d...@freebsd.org> wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote:
...
>>> Installed packages to be REMOVED:
>>> llvm40-4.0.0.r4
>>> 
>>> Number of packages to be removed: 1
>>> 
>>> The operation will free 49 GiB.
>> 
>> Yes, this is big.  But there is no real need to build the llvm ports
>> with debug information, unless you want to hack on llvm itself.  And
>> in that case, you are better served by a Subversion checkout or Git
>> clone from upstream instead.
...
> Historically unless something extreme like this ends up
> involved I build everything using WITH_DEBUG=  or explicit
> -g's in order to have better information on any failure.

The problem with the ports implementation of WITH_DEBUG is that it
always disables all optimizations, without a possibility to override.
Which bloats the resulting object files, libraries and executables, and
especially so for large C++ projects such as LLVM.

I can recommend the following workaround.  If you want to build a port
with optimizations disabled, you can always pass -O0 in CFLAGS.

-Dimitry

Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk  (revision 436685)
+++ Mk/bsd.port.mk  (working copy)
@@ -1646,7 +1646,7 @@ MAKE_ENV+=DONTSTRIP=yes
 STRIP_CMD= ${TRUE}
 .endif
 DEBUG_FLAGS?=  -g
-CFLAGS:=   ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+CFLAGS:=   ${CFLAGS} ${DEBUG_FLAGS}
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=   ${INSTALL_TARGET:S/^install-strip$/install/g}
 .endif



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 26 Mar 2017, at 23:36, Mark Millard  wrote:
> 
> I upgraded from llvm40 r4 to final. An interesting result was
> its creation of a backup package for llvm40-4.0.0.r4:
> 
> about 13 cpu-core-hours running pkg create
> 
> (Remember: I've been building with WITH_DEBUG= ) Its
> single-threaded status stands out via elapsed time
> approximately matching.
> 
> I'll note that it was somewhat under 6 elapsed hours for
> staging to have been populated (-j4 with 4 cores present
> helps for this part).
> 
> (Of course these elapsed-time figures are rather system
> dependent, although the ratio might be more stable.)
> 
> 
> 
> Also interesting was:
> 
> Installed packages to be REMOVED:
>   llvm40-4.0.0.r4
> 
> Number of packages to be removed: 1
> 
> The operation will free 49 GiB.

Yes, this is big.  But there is no real need to build the llvm ports
with debug information, unless you want to hack on llvm itself.  And
in that case, you are better served by a Subversion checkout or Git
clone from upstream instead.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: manpath change for ports ?

[Dimitry Andric]

On 9 Mar 2017, at 09:29, Dag-Erling Smørgrav  wrote:
...
> 1)
> 
> | I discovered that lang/gcc48 (and presumably the other gcc ports as
> | well) not only have /usr/local/include in their default include path,
> | but actually place it ahead of /usr/include.  This is causing me no end
> | of grief with software that uses iconv, because GNU libiconv's 
> | f*s up your namespace so the build fails unless you explicitly link with
> | GNU libiconv instead of using the libc version.  [...]
> 
> 2)
> 
> |  [...] I realized over the weekend that the
> | situation is even worse than I initially thought.  Basically, ports gcc
> | is unusable for any other purpose than to build ports which don't
> | support clang.  Let me explain with a hypothetical scenario:
> |
> | You are developing a library which is important enough that you need to
> | have the stable version installed on your development system.  It is
> | installed in /usr/local as usual.  You've been working on fixing a bug,
> | and have written a unit test which exercises the relevant code and
> | verified that it can deterministically trigger the bug.  You fix the bug
> | and 'make check' again, all green.  Then you clean out your working
> | copy, re-run configure with CC=gcc and 'make check' again.  Your tests
> | fail.
> |
> | What happened is that when you built your code with gcc, the tests were
> | linked and run with the stable version of the library, where the bug is
> | not fixed.  You can build with LDFLAGS=-L$(top_builddir)/lib, you can
> | even specify the full path to the library in LDADD for each individual
> | test, it doesn't matter.  It will *always* pick the installed version
> | first.  The only way to get your tests to pass is to not have the
> | library installed.

Please pin this email for re-use the next time a discussion is started
about adding /usr/local to the default include and library paths for the
base system compiler...  It's been more than a year now, so I expect
it to be regurgitated any time soon. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: seamonkey port compiling error

[Dimitry Andric]

On 26 Feb 2017, at 19:55, Erdos New via freebsd-ports 
 wrote:
> 
> i tried to install 'seamonkey' to my freebsd10.1 32-bit system.  however, 
> encountered errors:
> root@oblivion:/usr/ports/www/seamonkey # make install
> 
> 
> install seamonky:
> llvm[6]: Compiling IndexBody.cpp for Release build (PIC)
> llvm[6]: Compiling IndexDecl.cpp for Release build (PIC)
> llvm[6]: Compiling IndexTypeSourceInfo.cpp for Release build (PIC)
> llvm[6]: Compiling Indexing.cpp for Release build (PIC)
> llvm[6]: Compiling IndexingContext.cpp for Release build (PIC)
> llvm[6]: Linking Release Shared Library libclang.so
> llvm[6]: Building Release Archive Library libclang.a
> gmake[6]: Leaving directory 
> '/usr/ports/lang/clang36/work/llvm-3.6.2.src/tools/clang/tools/libclang'
> gmake[6]: Entering directory 
> '/usr/ports/lang/clang36/work/llvm-3.6.2.src/tools/clang/tools/c-index-test'
> llvm[6]: Compiling c-index-test.c for Release build
> llvm[6]: Linking Release executable c-index-test (without symbols)
> /usr/ports/lang/clang36/work/llvm-3.6.2.src/Release/lib/libLLVM-3.6.so: 
> undefined reference to `futimens@FBSD_1.4'

Most likely, you installed a binary package for devel/llvm36.  Binary
packages are now built on FreeBSD 10.3, the most recent supported
version for ports, and this version has introduced a new syscall which
your system does not have.

The simplest solution is probably to delete the llvm36 port, and rebuild
it on your 10.1 system.  Then try to rebuild the Seamonkey port and its
dependent ports again.

Though it would be easiest if you upgraded the system to 10.3. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: elf_load_section problem

[Dimitry Andric]

On 19 Feb 2017, at 21:30, Steve Kargl  wrote:
> 
> Looks like I picked the wrong time to update a month old.
> 
> Problem #1: 'kldload -v i915kms.ko' locks up the system.  No
> panic.  No messages logged.  No keyboard response.  Black
> screen of death.
> 
> Problem #2: 'kldload -v drm2.ko' locks up the system. No panic.
> No messages logged.  No keyboard response.  Black screen of death.
> 
> Problem #3: #1 and #2 along with an update of xorg to 1.18.4
> prevents X from firing up.
> 
> Problem #4: Ok. I re-install everything that X uses and their
> dependencies from source.

I can't help you with these...


> ===>  Building for help2man-1.47.4
> elf_load_section: truncated ELF file
> Abort trap

but this looks like a half-written or empty file.  Did you do a full
fsck, and did you already try cleaning out your work directory?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FreeBSD Port: libc -208080

[Dimitry Andric]

On 19 Feb 2017, at 14:18, Nathaniel Braun  wrote:
> I'd like to use the new variant class from C++17 on my FreeBSD machine.
> 
> I think that this class is available in LibC++ right now, but I did not 
> succeed in using it using the devel/libc++ port.
> 
> Would you know how to do that?

Don't use the devel/libc++ port, it is pretty much outdated.  It was
only created as a stopgap measure, and should really be deleted now that
FreeBSD 9.x is EOL.

In any case, at the moment, no released version of FreeBSD has a version
of libc++ new enough to support std::variant.  We are working on
importing clang and libc++ 4.0.0, in the projects/clang400-import
branch.  This version has std::variant support.

I expect this branch to be merged to FreeBSD 12 in a few weeks, then
merged to FreeBSD 11 at least a month later.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Firefox build fails

[Dimitry Andric]

On 12 Feb 2017, at 02:33, AN  wrote:
> FreeBSD BSD_12 12.0-CURRENT FreeBSD 12.0-CURRENT #13 r313546: Fri Feb 10 
> 10:04:11 EST 2017 root@BSD_12:/usr/obj/usr/src/sys/MYKERNEL  amd64
> 
> 
> Trying to install Firefox fails with the following:
> 
> ../../js/src/jsarray.o: In function 
> `js::NewFullyAllocatedArrayTryReuseGroup(JSContext*, JSObject*, unsigned 
> long, js::NewObjectKind, bool)':
> /usr/ports/www/firefox/work/firefox-51.0.1/js/src/jsarray.cpp:(.text._ZN2js35NewFullyAllocatedArrayTryReuseGroupEP9JSContextP8JSObjectmNS_13NewObjectKindEb+0xb59):
>  undefined reference to `__dtraceenabled_javascript___object__create'
> /usr/bin/ld: ../../js/src/jsarray.o: relocation R_X86_64_PC32 against 
> `__dtraceenabled_javascript___object__create' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value

Disable the DTRACE option, and try again.  See:

https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20170206/408053.html
https://lists.freebsd.org/pipermail/freebsd-ports/2017-February/107103.html
https://lists.freebsd.org/pipermail/freebsd-ports/2017-February/107138.html

and maybe even other threads.

Let's poke portmgr@ to just disable this option by default, until the port has 
been fixed.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Firefox build broken

[Dimitry Andric]

On 9 Feb 2017, at 14:03, Domagoj Stolfa  wrote:
> 
> It would seem that the firefox build is broken on 12.0-CURRENT. I've been
> getting the same error as seem on [1]. Has anyone else experienced this?
> 
> [1] 
> https://lists.freebsd.org/pipermail/freebsd-pkg-fallout/Week-of-Mon-20170206/408053.html

It's a problem in the DTRACE option.  See https://bugs.freebsd.org/216871 .

For now, if you don't need DTrace support, just turn it off.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: why a persistent GCC GCC49 conflict?

[Dimitry Andric]

On 20 Jan 2017, at 06:45, Jeffrey Bouquet via freebsd-ports 
 wrote:
> 
> pkg install driftnet wants to install gcc, and REMOVE
> truecrypt, gcc49, xpi-web-developer...[23 more]...sscalc.
> 
> This has been going on almost a half-year it seems.
> as gcc49 and gcc install files into the same place.
> 
> Before that several years, again IIRC, with no such specific
> problem...

For a long time, lang/gcc was gcc 4.8, which conflicted with the
lang/gcc48 port.  (Don't ask me why the gcc port maintainer has set it
up this way, I don't know :).

Recently, on 2016-11-20 [1], lang/gcc updated to become gcc 4.9, which
now conflicts with the lang/gcc49 port.  So lang/gcc49 must be removed,
together with all its dependent ports, before lang/gcc can be installed.

I don't know why pkg can't see this as a direct replacement.  Perhaps
pkg does not have support for such metadata.

-Dimitry

[1] https://svnweb.freebsd.org/ports?view=revision=426565



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: www/chromium build failure on 12-CURRENT

[Dimitry Andric]

On 11 Jan 2017, at 21:23, DutchDaemon - FreeBSD Forums Administrator 
<dutchdae...@freebsd.org> wrote:
> 
> On 11-1-2017 20:54, Dimitry Andric wrote:
> > On 11 Jan 2017, at 19:50, DutchDaemon - FreeBSD Forums
> > Administrator <dutchdae...@freebsd.org> wrote:
> 
> > This must be a different issue, but I don't see the missing header
> > you referred to in those log messages?  Do you have a full log
> > posted somewhere?
> 
> 'Missing header' is actually what Poudriere reports on its summary.
> 
> chromium-54.0.2840.100_1  www/chromiumbuild   0   missing_header
> 
> Full Poudriere output:
> 
> http://chopapp.com/#372r5yj

Ok, the actual error was just a few lines above:

../../third_party/angle/src/libANGLE/renderer/gl/glx/FunctionsGLX.cpp:15:10: 
fatal error: 'GL/glx.h' file not found
#include 
 ^
1 error generated.

So for some reason it cannot find your glx.h file.  Do you have the
libGL port installed?  I didn't see it being installed in the
build-depends stage.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: www/chromium build failure on 12-CURRENT

[Dimitry Andric]

On 11 Jan 2017, at 19:50, DutchDaemon - FreeBSD Forums Administrator 
 wrote:
> 
> On 11-1-2017 17:28, Steve Kargl wrote:
> > On Wed, Jan 11, 2017 at 11:01:21AM -0500, Shawn Webb wrote: >> Hey All, >> 
> > >> It looks like www/chromium fails to build on
> 12-CURRENT. Has anyone else >> run into this? >> > > Yep.  It is due to
> chasing bleeding edge clang. > >> >> clang++39 >> > >
> /c++/v1/__config:58:2: error: "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no >
> longer supported.  use
> _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR > instead > #error
> "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported. \ > ^ > 1 error
> generated. > > https://reviews.llvm.org/D27277 >
> I can't build it on 11 (latest patch level) either. It keeps throwing a
> 'missing header'. (Poudriere).
> 
> clang++39 -MMD -MF obj/third_party/angle/libANGLE/formatutilsgl.o.d
> -DLIBANGLE_IMPLEMENTATION -DV8_DEPRECATION_WARNINGS -DENABLE_MDNS=1
> -DENABLE_NOTIFICATIONS -DENABLE_PEPPER_CDMS -DENABLE_PLUGINS=1
> -DENABLE_PDF=1 -DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1
> -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1
> -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1
> -DUSE_CLIPBOARD_AURAX11=1 -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_GLIB=1
> -DUSE_NSS_CERTS=1 -DUSE_X11=1 -DNO_TCMALLOC -DENABLE_WEBRTC=1
> -DDISABLE_NACL -DENABLE_EXTENSIONS=1 -DENABLE_TASK_MANAGER=1
> -DENABLE_THEMES=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1
> -DENABLE_SESSION_SERVICE=1 -DENABLE_SUPERVISED_USERS=1
> -DENABLE_SERVICE_DISCOVERY=1 -DUSE_PROPRIETARY_CODECS
> -DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL
> -DCHROMIUM_BUILD -DENABLE_MEDIA_ROUTER=1 -DFIELDTRIAL_TESTING_ENABLED
> -DCR_CLANG_REVISION=278861-1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -D_LARGEFILE64_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
> -D_FORTIFY_SOURCE=2 -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
> -DANGLE_ENABLE_OPENGL -DANGLE_USE_X11 -DGL_GLEXT_PROTOTYPES
> -DEGL_EGLEXT_PROTOTYPES
> -DGL_APICALL=__attribute__\(\(visibility\(\"default\"\)\)\)
> -DEGLAPI=__attribute__\(\(visibility\(\"default\"\)\)\)
> -DANGLE_TRANSLATOR_STATIC
> -I../../third_party/angle/src/third_party/khronos -I/usr/local/include
> -Igen/angle -I../../third_party/angle/include
> -I../../third_party/angle/src
> -I../../third_party/angle/src/common/third_party/numerics
> -I../../third_party/angle/include -I../../third_party/angle/src
> -I../../third_party/angle/include -fno-strict-aliasing
> --param=ssp-buffer-size=4 -fstack-protector -funwind-tables -fPIC -pipe
> -fcolor-diagnostics
> -fdebug-prefix-map=/wrkdirs/usr/ports/www/chromium/work/chromium-54.0.2840.100=.
> -pthread -m64 -march=x86-64 -Wall -Wextra
> -Wno-missing-field-initializers -Wno-unused-parameter
> -Wno-c++11-narrowing -Wno-covered-switch-default
> -Wno-deprecated-register -Wno-unneeded-internal-declaration
> -Wno-inconsistent-missing-override -Wno-shift-negative-value
> -Wno-undefined-var-template -Wno-nonportable-include-path -O2 -fno-ident
> -fdata-sections -ffunction-sections -g0 -fvisibility=hidden
> -Wheader-hygiene -Wstring-conversion -D_THREAD_SAFE
> -fno-threadsafe-statics -fvisibility-inlines-hidden -std=gnu++11
> -fno-rtti -fno-exceptions -c
> ../../third_party/angle/src/libANGLE/renderer/gl/formatutilsgl.cpp -o
> obj/third_party/angle/libANGLE/formatutilsgl.o
> ninja: build stopped: subcommand failed.
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1

This must be a different issue, but I don't see the missing header you
referred to in those log messages?  Do you have a full log posted
somewhere?

-Dimitry




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: www/chromium build failure on 12-CURRENT

[Dimitry Andric]

On 11 Jan 2017, at 17:01, Shawn Webb  wrote:
> 
> It looks like www/chromium fails to build on 12-CURRENT.
...
> /usr/include/c++/v1/__config:58:2: error: "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is 
> no longer supported.use 
> _LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR instead
> #error "_LIBCPP_TRIVIAL_PAIR_COPY_CTOR" is no longer supported. \

Hi Shawn,

This has been fixed in https://svnweb.freebsd.org/changeset/ports/431170
(head) and https://svnweb.freebsd.org/changeset/ports/431185 (2017Q1).

See also https://bugs.freebsd.org/214654 .

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: several ports: clang include errors on 12

[Dimitry Andric]

On 10 Jan 2017, at 17:45, Raif S. Berent via freebsd-ports 
 wrote:
> 
> Hello. I'm trying the drm-next source tree (Macy et al.)
> Naturally I have to re-build all ports (appx 2100) for my testing.
> 
> Im getting a common build error for several ports (15+ so far) with fail 
> point as "compiler include" for: xmmintrin.h emmintrin.h cpuid.h
> 
> The poudriere build environment has ccache enabled and the "missing" includes 
> are under
> ~jail/usr/lib/clang/3.9.1/include/
> 
> Can anyone give some pointers where to look further? I have not tested with 
> ccache disabled, but since some 300 ports already built without problem, I 
> doubt the problem is ccache.
> I can't tell whether the source is per port or in a MK/bsd* file, the problem 
> involve sse2 AFIK, but world/kernel should not cause this?
> 
> Some pointers please on how to debug and I'll get to it...

As a rule, if you are having any compilation problem involving ccache, the 
first step is always to disable ccache, and see if the problem(s) go away.  If 
so, the issue is with ccache, otherwise it is something else.

That said, which ports are failing, in particular?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: What's happened to flashplugin?

[Dimitry Andric]

On 02 Jan 2017, at 11:05, Mike Clarke  wrote:
> 
> Both www/linux-c7-flashplugin24 and www/linux-c6-flashplugin24 appear
> to have been deleted from ports but I can't find information relating
> to why they've gone.

$ grep flashplugin /usr/ports/MOVED
www/linux-f8-flashplugin10||2011-04-04|Has expired: End of Life since Jan 7, 
2009
www/flashplugin-mozilla||2011-09-30|gplflash is no longer supported, please use 
graphics/gnash
www/asterisk-fop||2011-09-30|Depends on www/flashplugin-mozilla which is 
DEPRECATED
www/linux-flashplugin7||2011-10-14|Vulnerable since at least 2008-05-30
www/linux-f10-flashplugin10|www/linux-f10-flashplugin11|2012-08-26|Has expired: 
has vulnerabilities and is EOL
www/linux-flashplugin9||2013-04-16|Has expired: Vulnerable, Broken for more 
than 6 months
www/linux-f10-flashplugin11|www/linux-flashplayer|2016-12-13|Removed upstream
www/linux-c6-flashplugin11|www/linux-flashplayer|2016-12-13|Removed upstream
www/linux-c7-flashplugin11|www/linux-flashplayer|2016-12-13|Removed upstream
www/linux-c6-flashplugin24|www/linux-flashplayer|2016-12-18|Renamed to match 
upstream
www/linux-c7-flashplugin24|www/linux-flashplayer|2016-12-18|Renamed to match 
upstream


> Is this deletion permanent or can we expect a flash plugin to reappear?

It's been renamed to www/linux-flashplayer.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[Dimitry Andric]

On 29 Dec 2016, at 22:24, Ian Lepore <i...@freebsd.org> wrote:
> 
> On Thu, 2016-12-29 at 21:17 +0100, O. Hartmann wrote:
>> Am Thu, 29 Dec 2016 20:26:32 +0100
>> Dimitry Andric <d...@freebsd.org> schrieb:
...
>>> Do you have some Linux rdma or infiniband headers or libraries
>>> installed
>>> into /usr or /usr/local?  This might be the cause of the problems.
>> No Linux, but I found these files on all of the boxes in question:
>> 
>> locate rdma
>> 
>> [...]
>> /usr/include/rdma
>> /usr/include/rdma/rdma_cma.h
>> /usr/include/rdma/rdma_cma_abi.h
>> /usr/lib/librdmacm.a
>> /usr/lib/librdmacm.so
>> /usr/lib/librdmacm.so.1
>> 
>> ll usr/include/rdma discovers:
>> 
>> total 44
>> 322075 drwxr-xr-x   2 root  wheel  -  512B Oct  7 13:52 ./
>> 240768 drwxr-xr-x  55 root  wheel  -  6.5K Dec 29 19:14 ../
>> 324275 -r--r--r--   1 root  wheel  -   21K Oct  7 13:52 rdma_cma.h
>> 324276 -r--r--r--   1 root  wheel  -  4.7K Oct  7 13:52
>> rdma_cma_abi.h
...
> The rdma stuff is part of OFED, it comes from sys/ofed/include.  Other
> parts of it are in sys/contrib/rmda and src/contrib/ofed.  Maybe it
> only gets installed if you are using certain kernel options?  I'm not
> sure.

Indeed, this turns out to be enabled by WITH_OFED.  It then uses the
Makefile in contrib/ofed/include/rdma to install headers, and the
Makefile in contrib/ofed/usr.lib/librdmacm to install a library.

Unfortunately the headers aren't compatible with the qemu requirements,
so the port still needs to have --disable-rdma, in any case.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[Dimitry Andric]

On 29 Dec 2016, at 17:29, O. Hartmann <ohartm...@walstatt.org> wrote:
> 
> Am Wed, 7 Dec 2016 23:31:01 +0100
> Dimitry Andric <d...@freebsd.org> schrieb:
> 
>> On 07 Dec 2016, at 10:42, O. Hartmann <ohartm...@walstatt.org> wrote:
>>> 
>>> I try my first steps in cross compiling ports with poudriere and therefore 
>>> I try to
>>> setup an appropriate jail and QEMU environment.
>>> 
>>> Well, I'm failing at the jail setup due to the non-exitence of any suitable 
>>> QEMU
>>> environment and for that I tried to figure out to find some proper HOWTO.
>>> Searching via google ave some hints, but in questions which QEMU from ports 
>>> should be
>>> used, all leave me alone, so I tried
>>> 
>>> emulators/qemu
>>> emulators/qemu-devel
>>> emulators/qemu-static
>>> 
>>> emulators/qemu is known for me to fail since months and the days of 
>>> 11-CURRENT, there
>>> is a compiler error spit out with clang 3.8 and now 3.9. The very same for 
>>> qemu-devel
>>> (both ports used with standard options, no extras). See also Bug 214873
>>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
>>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).
>> 
>> I couldn't reproduce the compilation errors, it builds fine for me until
>> the link phase.
> 
> Well, I face this in poudriere on the most recent 12-CURRENT, too as well as 
> 12-CURRENT
> buildworld today.
> 
> On the host I'd like to run qemu for testing aarch64 binaries for a Odroid-C2 
> project, I
> use a customized /etc/src.conf - but on poudriere, there is no such 
> customisation but
> the failing is identical.

Looking at your errors, it seems that the port has decided to enable
rdma support.  This is normally enabled using --enable-rdma with the
configure script, but I don't see that at all in the port Makefile.

On my systems, it runs a test to check for rdma support, but this fails.
Quoting from config.log:

cc -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common 
-I/usr/work/share/dim/ports/emulators/qemu/work/qemu-2.6.1 -I/usr/local/include 
-DPREFIX=\""/usr/local\"" -Wno-string-plus-int -Wno-initializer-overrides 
-Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs 
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers 
-Wold-style-definition -Wtype-limits -fstack-protector-strong 
-I/usr/local/include -I/usr/local/include/p11-kit-1 -I/usr/local/include -o 
config-temp/qemu-conf.exe config-temp/qemu-conf.c -m64 -g -fstack-protector 
-L"/usr/local/lib" -lrdmacm -libverbs
config-temp/qemu-conf.c:1:10: fatal error: 'rdma/rdma_cma.h' file not found
#include 
 ^

The minimal test program it tries to compile here is just this:

#include 
int main(void) { return 0; }

and it attempts to link it with -lrdmacm -libverbs.  If this somehow
succeeds on your system, then it will think rdma support is available,
while apparently the support is not complete, if it misses the
rdma_getaddrinfo() function.

Do you have some Linux rdma or infiniband headers or libraries installed
into /usr or /usr/local?  This might be the cause of the problems.

If you don't want or care about rdma, you can try the following patch
(should similarly apply to the other qemu ports):

Index: emulators/qemu/Makefile
===
--- emulators/qemu/Makefile (revision 429888)
+++ emulators/qemu/Makefile (working copy)
@@ -78,6 +78,7 @@
--disable-libssh2 --enable-debug \
--prefix=${PREFIX} --cc=${CC} --enable-docs --disable-kvm \
--disable-linux-user --disable-linux-aio --disable-xen \
+   --disable-rdma \
--smbd=${LOCALBASE}/sbin/smbd --enable-debug-info 
--python=${PYTHON_CMD} \
--extra-cflags=-I${WRKSRC}\ -I${LOCALBASE}/include\ 
-DPREFIX=\\\"\"${PREFIX}\\\"\"

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: emulators/qemu: qemu ports failing due to compiler error on 12-CURRENT

[Dimitry Andric]

On 07 Dec 2016, at 10:42, O. Hartmann  wrote:
> 
> I try my first steps in cross compiling ports with poudriere and therefore I 
> try to setup
> an appropriate jail and QEMU environment.
> 
> Well, I'm failing at the jail setup due to the non-exitence of any suitable 
> QEMU
> environment and for that I tried to figure out to find some proper HOWTO.
> Searching via google ave some hints, but in questions which QEMU from ports 
> should be
> used, all leave me alone, so I tried
> 
> emulators/qemu
> emulators/qemu-devel
> emulators/qemu-static
> 
> emulators/qemu is known for me to fail since months and the days of 
> 11-CURRENT, there is a
> compiler error spit out with clang 3.8 and now 3.9. The very same for 
> qemu-devel (both
> ports used with standard options, no extras). See also Bug 214873
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214873) and Bug 215100
> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215100).

I couldn't reproduce the compilation errors, it builds fine for me until
the link phase.


> I tried also emulators/qemu-static, but it also fails compiling on most 
> recent 12-CURRENT
> (as the others, too, also my poudriere environment, which has also CURRENT 
> jails) with
> 
> [...]
> /usr/bin/ld:../config-host.ld:14: syntax error
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> [...]

But this I *can* reproduce.  It appears qemu wants to set the text
segment start address, using the -Ttext-segment=0x6000 option to ld.

However, our base ld does not yet support this option, and then the
configure script tries to patch the default linker script using the
following construct:

  $ld --verbose | sed \
-e '1,/==/d' \
-e '/==/,$d' \
-e "s/[.] = [0-9a-fx]* [+] SIZEOF_HEADERS/. = $textseg_addr + 
SIZEOF_HEADERS/" \
-e "s/__executable_start = [0-9a-fx]*/__executable_start = 
$textseg_addr/" > config-host.ld

Unfortunately, it seems to run /usr/local/bin/ld in this case, and this
results in the following busted linker script line, which cannot be
parsed:

  PROVIDE (__executable_start = 0x6000SEGMENT_START("text-segment", 
0x08048000)); . = SEGMENT_START("text-segment", 0x08048000) + SIZEOF_HEADERS;

If it would use /usr/bin/ld instead, the patching would succeed, and
the line would become:

  PROVIDE (__executable_start = 0x6000); . = 0x6000 + SIZEOF_HEADERS;

which is probably what was intended.

Probably, the configure script needs to be patched to run base ld,
or use the same ld invocation for both checking the -Ttext-segment
option support and patching the linker script.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problems are a Curl upgrade on 12.0 current of Sun Oct 2

[Dimitry Andric]

On 05 Dec 2016, at 15:44, Willem Jan Withagen  wrote:
> 
> Now some of my lining attempts give me:
> 
> /usr/local/lib/libcurl.so: undefined reference to `basename@FBSD_1.5
> I guess that that libc has become versioned, of the version number got
> bumpped?
> 
> So would I need to rebuild world?

Yes, this was changed by Ed in r308264:

https://svnweb.freebsd.org/base?view=revision=308264

Although I would think there might have been a backwards compat symbol...

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Dimitry Andric]

On 26 Nov 2016, at 01:13, Mark Millard  wrote:
> 
>> Author: dim (src committer)
>> Date: Fri Nov 25 12:54:01 2016
>> New Revision: 427110
>> URL:
>> https://svnweb.freebsd.org/changeset/ports/427110
>> 
>> 
>> Log:
>>  Fix build of lang/gcc with libc++ 3.9.0, similar to r421625:
>> . . .
>>  What is happening here, is that the source file includes gcc/system.h,
>>  which defines abort to fancy_abort, and then the source file includes
>>  , which attempts to call _VSTD::abort() (the _VSTD is a libc++
>>  alias for std::).  The macro definition then causes the above breakage.
>> 
>>  Newer gcc ports, such as gcc5 and gcc6 don't show this issue, because
>>  upstream gcc first added an include of  (which indirectly
>>  includes ) in r217348 [1], and later even add a direct include of
>>   in r232736 [2].
>> 
>>  Fix it for this version, by adding the direct include of  to
>>  gcc/system.h.  This makes the 'second' includes of  in some .c
>>  files superfluous, but at least they won't result in errors.
> 
> Will lang/gcc49 needs similar changes?

Actually, the patch was copied from the lang/gcc49 port, which had
already been fixed earlier, in r421625.


> (I normally only use explicitly version numbered lang/gcc* 's and
> I use lang/gcc49 on powerpc64's.)

Well, lang/gcc is a special case, in the sense that some ports that have
USE_GCC=yes, e.g. with an unspecified version, will default to it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: devel/llvm38 install seems to be missing files (e.g., FileCheck)

[Dimitry Andric]

On 05 Nov 2016, at 16:58, Rainer Hurling  wrote:
> 
> Am 05.11.2016 um 14:54 schrieb David Wolfskill:
>> On Sat, Nov 05, 2016 at 05:26:33AM -0700, David Wolfskill wrote:
>>> ...
>>> I circumvented the problem: ...
>>> 
>>> g1-252(11.0-S)[20] sudo cp -p !$ /usr/local/llvm38/bin/
>>> sudo cp -p work/stage/usr/local/llvm38/bin/FileCheck /usr/local/llvm38/bin/
>>> g1-252(11.0-S)[21]
>>> 
>>> That done, lang/rust built.
>>> 
>>> My build machine is doing the first of its weekend poudriere runs
>>> as I type; if that shows anything relevant with respect to lang/rust
>>> and devel/llvm38, I'll follow up.
>>> 
>> 
>> Turns out that "PORT_LLVM" is, by default, off; I had turned it on since
>> I had other reasons to need llvm38 anyway.
>> 
>> And since I only use lang/rust as a build dependency (e.g., for
>> www/fierfox), I had not specified any non-default options for the
>> poudriere build.  Thus, poudriere had built rust using the "bundled"
>> llvm38, which apparently has FileCheck in the place where the rust
>> config looks for it.  So poudriere didn't have an issue building
>> www/firefox (which required lang/rust).
>> 
>> Am I incorrect in thinking that devel/llvm38 has a problem, though, in
>> that "%%LIT%%llvm38/bin/FileCheck" is in that port's pkg-plist, and
>> llvm38/bin/FileCheck is found in the staging directory, but
>> llvm38/bin/FileCheck is not actually installed?
> 
> not sure, if I missed something in your postings.
> 
> On my boxes, all recent FreeBSD 12.0-CURRENT amd64, the port
> devel/llvm38 installed FileCheck as expected, in the two places
> /usr/local/llvm38/bin/ and /usr/local/bin/.

It's installed into /usr/local/bin with a version number suffix, e.g.:

$ pkg info -l llvm38|grep FileCheck
/usr/local/bin/FileCheck38
/usr/local/llvm38/bin/FileCheck
/usr/local/man/man1/FileCheck38.1.gz
/usr/local/share/doc/llvm38/llvm/html/CommandGuide/FileCheck.html

/usr/local/share/doc/llvm38/llvm/html/_sources/CommandGuide/FileCheck.txt

Maybe that's the reason rust can't find it in OP's case?  (It works just fine 
for me, btw.)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problem with gcc5 std library when building ports

[Dimitry Andric]

On 27 Oct 2016, at 01:01, Dewayne Geraghty  wrote:
> 
> Can anyone help regarding the apparant absence of snprintf from std?  Am I
> missing something, perhaps LDCONFIG or?  I've looked in /usr/ports/Mk/
> bsd.gcc.mk and /usr/ports/Mk/bsd.port.mk but this is an area that I'm
> unfamiliar, so nothing really stood out.
> 
> If I change the compiler from gcc5 to clang everything compiles and runs
> correctly. I have in /etc/make.conf
> USE_GCC=  5
> and to use clang, I just comment out the above. So everything is constant,
> on FreeBSD 10.3Stable (updated and rebuilt overnight)

The difference is that clang by default uses libc++, while gcc uses
libstcd++.  Unfortunately, our gcc ports have a long-standing problem
with recognition of C99 functionality for their copies of libstdc++.

If you look in gcc5's  header, usually located in
/usr/local/lib/gcc5/include/c++/cstdio, you will see this:

#if _GLIBCXX_USE_C99

#undef snprintf
[...]

namespace __gnu_cxx
{
#if _GLIBCXX_USE_C99_CHECK || _GLIBCXX_USE_C99_DYNAMIC
  extern "C" int
  (snprintf)(char * __restrict, std::size_t, const char * __restrict, ...)
  throw ();
[...]
#endif

#if !_GLIBCXX_USE_C99_DYNAMIC
  using ::snprintf;
[...]
#endif
} // namespace __gnu_cxx

namespace std
{
  using ::__gnu_cxx::snprintf;
[...]
} // namespace std

#endif // _GLIBCXX_USE_C99

So in a slightly convoluted way, it only defines std::snprintf() when
_GLIBCXX_USE_C99 is defined.

However, during the port build, the gcc configuration mechanism seems to
conclude that C99 support is *not* available, and stores this in
/usr/local/lib/gcc5/include/c++/${ARCH}-portbld-freebsd${VERSION}/bits/c++config.h:

/* Define if C99 functions or macros from , , ,
   , and  can be used or exposed. */
/* #undef _GLIBCXX_USE_C99 */

This has been the case for ages now, and there must be lots of bug
reports for it, but it has not been fixed.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[Dimitry Andric]

On 07 Oct 2016, at 13:59, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 07 Oct 2016, at 13:43, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
...
>> YES :-(
>> 
>> /usr/include/include does exist ...
> 
> Right, so that is pretty strange.  Maybe it was an artefact of some
> failed installation?  In any case, I would blow it away.
> 
> Btw, it looks like the eigen port uses pkgconfig, can you please post
> the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?

For reference, on my system where I just freshly compiled eigen3, the
contents is this:


prefix=/usr/local
exec_prefix=${prefix}

Name: Eigen3
Description: A C++ template library for linear algebra: vectors, matrices, and 
related algorithms
Requires:
Version: 3.2.10
Libs:
Cflags: -I${prefix}/include/eigen3


-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[Dimitry Andric]

On 07 Oct 2016, at 13:43, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
> 
> Am Fri, 7 Oct 2016 13:27:19 +0200
> Dimitry Andric <d...@freebsd.org> schrieb:
>> On 07 Oct 2016, at 10:26, O. Hartmann <ohart...@zedat.fu-berlin.de> wrote:
...
>>> In file included
>>> from 
>>> /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
>>> In file included from /usr/include/c++/v1/algorithm:624: In file included
>>> from /usr/include/c++/v1/initializer_list:47: 
>>> /usr/include/c++/v1/cstddef:43:15: fatal
>>> error: 'stddef.h' file not found #include_next 
>> 
>> So for some reason, on your system, the compilation flags include
>> -isystem /usr/include/include, which is rather strange.  I would not
>> expect this to break compilation in the fashion you are seeing.  Do you
>> have an /usr/include/include directory on your system, by any chance?
> 
> YES :-(
> 
> /usr/include/include does exist ...

Right, so that is pretty strange.  Maybe it was an artefact of some
failed installation?  In any case, I would blow it away.

Btw, it looks like the eigen port uses pkgconfig, can you please post
the contents of your /usr/local/libdata/pkgconfig/eigen3.pc file?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: graphics/opencv2-core: compiler error on CURRENT: error: 'stddef.h' file not found

[Dimitry Andric]

On 07 Oct 2016, at 10:26, O. Hartmann  wrote:
> 
> I'm being haunted by this error on two CURRENT systems, while several other 
> CURRENT
> systems with identical src.conf and make.conf are not affected, please see 
> below.
...
> cd /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core && 
> /usr/bin/c++
> -DCVAPI_EXPORTS
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/dynamicuda/include
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/src
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include
> -I/usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1
> -isystem /usr/local/include/eigen3 -isystem /usr/include/include -O2 -pipe -O3
> -march=native -fstack-protector -fno-strict-aliasing   -fsigned-char -W
> -Werror=return-type -Werror=address -Werror=sequence-point -Wformat
> -Werror=format-security -Wmissing-declarations -Wmissing-prototypes 
> -Wstrict-prototypes
> -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wno-narrowing
> -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -Wno-array-bounds
> -fdiagnostics-show-option -Wno-long-long -pthread -fomit-frame-pointer -msse 
> -msse2 -mavx
> -mavx2 -ffunction-sections -O2 -pipe -O3 -march=native -fstack-protector
> -fno-strict-aliasing  -DNDEBUG -fPIC -o 
> CMakeFiles/opencv_core.dir/src/arithm.cpp.o
...
> In file included
> from 
> /usr/ports/graphics/opencv2-core/work/opencv-2.4.13.1/modules/core/include/opencv2/core/core.hpp:53:
> In file included from /usr/include/c++/v1/algorithm:624: In file included
> from /usr/include/c++/v1/initializer_list:47: 
> /usr/include/c++/v1/cstddef:43:15: fatal
> error: 'stddef.h' file not found #include_next 

So for some reason, on your system, the compilation flags include
-isystem /usr/include/include, which is rather strange.  I would not
expect this to break compilation in the fashion you are seeing.  Do you
have an /usr/include/include directory on your system, by any chance?

That said, for me graphics/opencv2-core compiles just fine, and the
compilation flags only have an -isystem option to point at the
/usr/local/include/eigen3 directory.

Maybe the problem lies in the eigen3 port?  I assume this will have a
pkg-config file, or some other way at getting the required CFLAGS and
CXXFLAGS for using it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: HTML5 videos crashes Firefox

[Dimitry Andric]

On 23 Sep 2016, at 11:35, Robert_Burmeister  
wrote:
> I was able to resolve HTML5 videos crashes in Firefox 49 on FreeBSD 10.3 i386
> by changing the FFMPEG compile option to "SSE=off" and recompiling FFMPEG.
> 
> The LLVM compiler was not dealing with an SSE bug on my older core2 CPU.

I can't reproduce your particular crashes, but in the past I had created
a patch to force the FFmpeg build to use stack realignment.  Can you
please try it out?  E.g. put the attched patch in the root of your ports
folder, and run:

  patch -p0 -f -F0 -i multimedia__ffmpeg-force-i386-stack-realign-1.diff

This patch is needed, because FFmpeg assumes a 16-byte aligned stack,
even on i386, where the ABI specifies a 4-byte alignment.  On Linux,
this ABI requirement was basically dumped at some point, leaving old
applications in the cold, but not on FreeBSD.

-Dimitry


multimedia__ffmpeg-force-i386-stack-realign-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: binutils 2.27 [not working for powerpc64 (and powerpc?)]

[Dimitry Andric]

Has anyone succeeded in bisecting upstream binutils, to see where this problem 
was introduced?

-Dimitry

On 20 Sep 2016, at 22:56, Mark Millard  wrote:
> 
> The below forward from freebsd-pcc's list confirms that binutils 2.27 not 
> working for powerpc64 (& powerpc?) contexts.
> 
> Note: Krzysztof Parzyszek is one of the two people that have recently been 
> working on updating clang/llvm for fixing some of the issues that block 
> FreeBSD from using clang for powerpc and powerpc64 for buildworld and 
> buildkernel.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Sep-20, at 11:19 AM, Krzysztof Parzyszek  
> wrote:
> 
>> I've had similar problems after building gcc-4.8.  After reverting back to 
>> binutils 2.25 and rebuilding, it worked fine.
>> 
>> -Krzysztof
>> 
>> On 9/9/2016 11:32 AM, Bill Sorenson wrote:
>>> Everything I've built with the new binutils using either GCC 4.9, 5.4 or
>>> 6.2 instantly dumps when run. This is on an Xserve G5. Is this just me or
>>> is there something genuinely broken here?
>>> 
>>> Thanks,
>>> Bill



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: codecvt and libc++ on FreeBSD 9.x

[Dimitry Andric]

On 01 Sep 2016, at 20:39, Ben Lavery  wrote:
...
> In file included from /root/bunnysay/work/bunnysay-1.0/src/BunnySay.cpp:22:0:
> /root/bunnysay/work/bunnysay-1.0/src/BunnySay.h:33:19: fatal error: codecvt: 
> No such file or directory
> #include 
...
> On the submission (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212278) 
> CPM has said of the issue "Second it seems that codecvt is missing, so it 
> needs libc++ support" - but I'm not sure how to add this.  I've tried adding 
> the following which I found in multiple threads on the forums, but to no 
> avail:
> 
> CC=clang
> CXX=clang++
> CPP=clang-cpp
> WITH_LIBCPLUSPLUS=yes

Putting this in your make.conf, then rebuilding world and installing it,
will install libc++ headers and libraries into your base system.  That
is step one.

Step two is to add -stdlib=libc++ to your clang command line.  On 9.x
and earlier, clang uses libstdc++ by default, so you have to actively
tell it to use libc++.


> I *think* this is because clang is too old on FreeBSD 9.3?

FreeBSD 9.3 has clang 3.4.1, which should be new enough, but libc++ is
not installed by default.

> But I'm not sure if I can/should reference a newer version from ports (and 
> how to go about this in the proper way), and how to make this apply to 
> FreeBSD 9.x only as it works fine "as is" on FreeBSD 10.

You could make it depend on the devel/libc++ port, as some other ports
do.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail