FreeBSD ports you maintain which are out of date

2015-03-16 Thread portscout
Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
print/lilypond-devel| 2.19.11 | 2.19.17
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

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


FreeBSD Port: php5-5.4.38

2015-03-16 Thread Zalysin Maxim
Hello!
I am write more functional rc.d script for php-fpm - 
https://github.com/MAXuk/php-fpm-rc-script 

This script tested on php5.3, php5.4 and php5.6.
Maybe it will be interesting to your and added this in freebsd ports.

Thanks.
—
Maxim Zalysin

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

textproc/clucene: pkg-static: sqlite error while executing INSERT OR REPLACE INTO packages

2015-03-16 Thread O. Hartmann
Since today's CURRENT update (running FreeBSD 11.0-CURRENT #1 r280149: Mon Mar 
16
19:41:00 CET 2015 amd64) I receive this nasty error on a box while updating 
ports:

textproc/clucene:

Installing clucene-2.3.3.4_5... pkg-static: sqlite error while executing INSERT 
OR
REPLACE INTO packages( origin, name, version, comment, desc, message, arch, 
maintainer,
www, prefix, flatsize, automatic, licenselogic, mtree_id, time, manifestdigest)
VALUES( ?1, ?2, ?3, ?4, ?5, ?6, ?7, ?8, ?9, ?10, ?11, ?12, ?13, (SELECT id FROM 
mtree
WHERE content = ?14), NOW(), ?15) in file pkgdb.c:1602: FOREIGN KEY constraint 
failed ***
Error code 70

It seems that something went wrong after the system's update and I have no clue 
what it
could mean. Filesystem doesn't seem to be corrupted.

Is there a way to solve this problem?

Please CC me, I'm not subscribing the list.

Regards and thanks in advance,

Oliver 


pgpYusxawXAKM.pgp
Description: OpenPGP digital signature


net/unison240 depends on lang/ocaml-nox11

2015-03-16 Thread Jeremie Le Hen
Hi Guido,

I saw you recently submitted net/unison240 but it depends on
lang/ocaml-nox11.  This is a problem with using poudriere:

[00:00:58] >> Error: Duplicated origin for ocaml-nox11-4.01.0_4:
lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are
depending on these.

Would you mind making it similar to www/unison232?  This one works correctly.

Thanks a lot.
Cheers,
-- 
Jeremie Le Hen
j...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: net/unison240 depends on lang/ocaml-nox11

2015-03-16 Thread Jeremie Le Hen
Actually, I've just realized that I fixed net/unison232 in my local tree :o).

Would you mind submitting it and applying the same for unison240?

Here is the patch:

Index: Makefile
===
--- Makefile(revision 381259)
+++ Makefile(working copy)
@@ -34,20 +34,18 @@

 .include 

+BUILD_DEPENDS+=ocamlc:${PORTSDIR}/lang/ocaml
 .if ${PORT_OPTIONS:MX11}
 MAKE_ARGS+=UISTYLE=gtk2
 PLIST_SUB+=TEXT=""
-BUILD_DEPENDS+=ocamlc:${PORTSDIR}/lang/ocaml \
-   lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \
+BUILD_DEPENDS+=lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2 \
icotool:${PORTSDIR}/graphics/icoutils
 RUN_DEPENDS+=  lablgtk2:${PORTSDIR}/x11-toolkits/ocaml-lablgtk2
 PATCH_DEPENDS+=${BUILD_DEPENDS}
-CONFLICTS+=ocaml-nox11*
 SUB_FILES+=${PORTNAME}.desktop
 .else
 MAKE_ARGS+=UISTYLE=text
 PLIST_SUB+=TEXT="@comment "
-BUILD_DEPENDS+=ocamlc:${PORTSDIR}/lang/ocaml-nox11
 PATCH_DEPENDS+=${BUILD_DEPENDS}
 .endif



On Mon, Mar 16, 2015 at 10:33 PM, Jeremie Le Hen  wrote:
> Hi Guido,
>
> I saw you recently submitted net/unison240 but it depends on
> lang/ocaml-nox11.  This is a problem with using poudriere:
>
> [00:00:58] >> Error: Duplicated origin for ocaml-nox11-4.01.0_4:
> lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are
> depending on these.
>
> Would you mind making it similar to www/unison232?  This one works correctly.
>
> Thanks a lot.
> Cheers,
> --
> Jeremie Le Hen
> j...@freebsd.org



-- 
Jeremie Le Hen
j...@freebsd.org
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"


Re: net/unison240 depends on lang/ocaml-nox11

2015-03-16 Thread Guido Falsi
On 03/16/15 22:37, Jeremie Le Hen wrote:
> Actually, I've just realized that I fixed net/unison232 in my local tree :o).
> 
> Would you mind submitting it and applying the same for unison240?
> 

I never noticed this since it never happened to me and nobody else
reported it.

Anyway now that you draw my attention, yes, it needs fixing.

Your patch looks correct, but please allow me a little time for some
testing.

Thanks for bringing this up!

>> [00:00:58] >> Error: Duplicated origin for ocaml-nox11-4.01.0_4:
>> lang/ocaml-nox11 AND lang/ocaml. Rerun with -vv to see which ports are
>> depending on these.

Just to be sure I get it right, is this error reported at the start of
the run while "Calculating ports order and dependencies"?

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


powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)

2015-03-16 Thread Mark Millard
Basic context (more context details listed later):

# freebsd-version -ku; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
19:23:14 PDT 2015 
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
powerpc powerpc64


The problem:

portmaster -tDK --no-confirm lang/clang36 is how I started the build.

The error report was after it reported entering the directory:

/usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/

The report was:

llvm-build: error: invalid native target: 'powerpc64' (not in project)


I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 likely 
does. I've not yet tried from a powerpc (non-64) FreeBSD build.

I'll note that with top -PaSCHopid I watched it compile the PowerPc code 
generator software: it shoudl be able to handle PowerPCs fine.

My guess is a conversion of naming conventions is required someplace:

FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.)

This likely would matter for little endian naming as well (ppc64le on the clang 
end of things I expect). 




Context details:

# svnlite info /usr/ports/lang/clang36
Path: lang/clang36
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
Relative URL: ^/head/lang/clang36
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 380295
Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015)

It used gcc5 to bootstrap as there was no clang present and that is the only 
gcc port installed:

# svnlite info /usr/ports/lang/gcc5
Path: lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 380943
Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015)

# more /etc/make.conf
#CPP=clang-cpp
#CC=clang
#CXX=clang++
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=


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

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


powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
Basic context (more context details listed later):

# freebsd-version -ku; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
19:23:14 PDT 2015 
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
powerpc powerpc64


The problem:

portmaster -tDK --no-confirm lang/clang36 is how I started the build.

The error reported was for in MSVCToolChain.cpp's member function:

bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, 
int&) const

The report was:

MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared
::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);


I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being 
likely to be powerpc64 specific would be my guess. May be that it bootstrapped 
via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build.



Context details:

# svnlite info /usr/ports/lang/clang36
Path: lang/clang36
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
Relative URL: ^/head/lang/clang36
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 380295
Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015)

It used gcc5 to bootstrap as there was no clang present and that is the only 
gcc port installed:

# svnlite info /usr/ports/lang/gcc5
Path: lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 380943
Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015)

# more /etc/make.conf
#CPP=clang-cpp
#CC=clang
#CXX=clang++
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=

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

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


Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Nathan Whitehorn
Which compiler are you building with? Just using the normal lang/gcc 
works for me without issue doing make install in lang/clang36. Are you 
sure you don't have any local diffs or stale files?

-Nathan

On 03/16/15 17:18, Mark Millard wrote:

Basic context (more context details listed later):

# freebsd-version -ku; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
19:23:14 PDT 2015 
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
powerpc powerpc64


The problem:

portmaster -tDK --no-confirm lang/clang36 is how I started the build.

The error reported was for in MSVCToolChain.cpp's member function:

bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, 
int&) const

The report was:

MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared
::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);


I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being 
likely to be powerpc64 specific would be my guess. May be that it bootstrapped 
via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build.



Context details:

# svnlite info /usr/ports/lang/clang36
Path: lang/clang36
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
Relative URL: ^/head/lang/clang36
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 380295
Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015)

It used gcc5 to bootstrap as there was no clang present and that is the only 
gcc port installed:

# svnlite info /usr/ports/lang/gcc5
Path: lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 380943
Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015)

# more /etc/make.conf
#CPP=clang-cpp
#CC=clang
#CXX=clang++
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=

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

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



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


Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
> On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn  wrote:
> 
> Which compiler are you building with? Just using the normal lang/gcc works 
> for me without issue doing make install in lang/clang36. Are you sure you 
> don't have any local diffs or stale files?
> -Nathan

Quoting for the "which compiler" part: "It used gcc5 to bootstrap as there was 
no clang present and that is the only gcc port installed".

The evidence for this was watching top -PaSCHopid while it worked on the 
installation.

As for the FBSDG5C0 SSD's 11.0-CURRENT history for compilers:

gcc 4.2.1 present.

clang not present.
(Not 3.4.1, not 3.5, not 3.6.
 3.4.1 was lost in the 10.1-STABLE -> 11.0-CURRENT conversion when I did 
delete-old,
 not realizing that I'd end up with no clang at all and no obvious way to build 
one
 on the powerpc64s/powerpcs.)

(None of the below were ever on any 10.1-STABLE SSD as of when I did the copies 
and conversion of some to 11.0-CURRENT.)

powerpc64-xtoolchain-gcc present (and so powerpc64-gcc), installed recently for 
the first time ever. This was the first ever not-built-into-world compiler that 
I've installed on any media. The powerpc64-gcc installer has a file naming 
problem for powerpc64 hosts I had to put copies of 5 files that it created 
under the names it later looked for them to finish this install (names not 
prefixed -> prefixed, one file copied to another place).

gcc5 installed just days ago, the second ever ports-compiler installed. The 
install had no problems.



I will note that I have started an installation of lang/clang36 on a powerpc 
(non-64) 11.0-CURRENT that has/had only gcc 4.2.1 and clang 3.4.1. Watching 
with top -PaSCHopid shows that it is doing a lang/gcc installation as part of 
its bootstrap, at this point that means 4.8.4.

So it is not using gcc 4.2.1. Again for this SSD there is no history of 
compiler installs other than those that are part of world. clang 3.4.1 exists 
because I did not get around to doing delete-old before I noticed that I ended 
up with no clang as a result. This is the only copy of clang 3.4.1 that 
survived my ignorance to end up on 11.0-CURRENT.

I have another powerpc (non-64) 11.0-CURRENT SSD that does not have 
powerpc64-gcc nor clang but does have gcc5 already. Again gcc5 installed in the 
last few days. Again before the installation there had only ever been 
built-into-world compilers. I've started a lang/CLANG36 install here as well.

We will see how each of these goes.



Side note: You can tell I got past the booting/memory-corruption problems on 
the G5 PowerMacs recently (via Powermac specific builds). I'm now exploring 
other things in FreeBSD. :)


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

On 2015-Mar-16, at 06:23 PM, Nathan Whitehorn  wrote:

Which compiler are you building with? Just using the normal lang/gcc works for 
me without issue doing make install in lang/clang36. Are you sure you don't 
have any local diffs or stale files?
-Nathan

On 03/16/15 17:18, Mark Millard wrote:
> Basic context (more context details listed later):
> 
> # freebsd-version -ku; uname -ap
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
> 19:23:14 PDT 2015 
> root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
> powerpc powerpc64
> 
> 
> The problem:
> 
> portmaster -tDK --no-confirm lang/clang36 is how I started the build.
> 
> The error reported was for in MSVCToolChain.cpp's member function:
> 
> bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, 
> int&) const
> 
> The report was:
> 
> MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared
> ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);
> 
> 
> I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being 
> likely to be powerpc64 specific would be my guess. May be that it 
> bootstrapped via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD 
> build.
> 
> 
> 
> Context details:
> 
> # svnlite info /usr/ports/lang/clang36
> Path: lang/clang36
> Working Copy Root Path: /usr/ports
> URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
> Relative URL: ^/head/lang/clang36
> Repository Root: https://svn0.us-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 381120
> Node Kind: directory
> Schedule: normal
> Last Changed Author: brooks
> Last Changed Rev: 380295
> Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015)
> 
> It used gcc5 to bootstrap as there was no clang present and that is the only 
> gcc port installed:
> 
> # svnlite info /usr/ports/lang/gcc5
> Path: lang/gcc5
> Working Copy Root Path: /usr/ports
> URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
> Relative URL: ^/head/lang/gcc5
> Repository Root: https://svn0.us-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 381120
> Node Kind: directory
> Schedule: normal
> Last Changed Auth

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc (non-64):

$ freebsd-version -ku ; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar  9 
22:24:27 PDT 2015 root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG  
powerpc powerpc

Again it used gcc5 to bootstrap, my having installed gcc5 recently, no other 
non-built-in-world compilers ever having been installed before. No clang of any 
kind to start with. Just gcc 4.2.1. No changes to lang/clang36. Just:

portmaster -tDK --no-confirm lang/clang36

Again it had the same MSVCToolChain.cpp problem:

llvm[4]: Compiling MSVCToolChain.cpp for Release build
MSVCToolChain.cpp: In member function 'bool 
clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::string&,
 int&, int&) const':
MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared
 ::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);
 ^

Like before when I had installed gcc5 it had no troubles installing and I made 
no changes.


I have another build test running where only built-in-world compilers existed 
(gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK --no-confirm 
lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at this point) in 
order to provide itself with a compiler to bootstrap with. We will see how that 
one does. It takes longer since 2 compilers are being installed. (I started 
this one first but it is not done yet.)


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

On 2015-Mar-16, at 05:18 PM, Mark Millard  wrote:

Basic context (more context details listed later):

# freebsd-version -ku; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
19:23:14 PDT 2015 
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
powerpc powerpc64


The problem:

portmaster -tDK --no-confirm lang/clang36 is how I started the build.

The error reported was for in MSVCToolChain.cpp's member function:

bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, 
int&) const

The report was:

MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared
::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);


I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being 
likely to be powerpc64 specific would be my guess. May be that it bootstrapped 
via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build.



Context details:

# svnlite info /usr/ports/lang/clang36
Path: lang/clang36
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
Relative URL: ^/head/lang/clang36
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 380295
Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015)

It used gcc5 to bootstrap as there was no clang present and that is the only 
gcc port installed:

# svnlite info /usr/ports/lang/gcc5
Path: lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 380943
Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015)

# more /etc/make.conf
#CPP=clang-cpp
#CC=clang
#CXX=clang++
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=

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


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


Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets another error: llvm-build: error: '::sscanf' has not been declared

2015-03-16 Thread Mark Millard
The last powerpc (non-64) build test to complete ran where only built-in-world 
compilers originally existed (gcc 4.2.1 and clang 3.4.1 this time. For this 
context "portmaster -tDK --no-confirm lang/clang36" initiated installing 
lang/gcc (i.e., 4.8.4 at this point) in order to provide itself with a compiler 
to bootstrap with.

The result: no failures and a full clang 3.6 installation by being bootstrapped 
via gcc 4.8.4.

So gcc 4.8.4 vs. gcc5 makes a difference. But before blaming gcc5 
specifically...

Here is what I would guess is going on:

llvm's source code sometimes uses  and other times . (I did 
find with grep's.) One would have to trace all the headers actually included 
for MSVCToolChain.cpp, directly or indirectly, and see which one(s) are 
involved.

But for ::sscanf notation they should be explicitly including  
somewhere for that context. (Having  in addition is fine.)


The rule is as follows, using an example. The C++ standard (various vintages) 
has at least one vintage that uses  vs.  as an example for...

"The header  assuredly provides its declarations and definitions 
within the namespace std. It may also provide these names within the global 
namespace. The header  assuredly provides the same declarations and 
definitions within the global namespace, much as in the C Standard. It may also 
provide these names within the namespace std."

So...

 only guarantees:

int std::sscanf( const char* buffer, const char* format, ... );

 only guarantees:

int ::sscanf( const char* buffer, const char* format, ... );

But either file is allowed to (not required to) also declare/define the other 
alternative as well.


In other words: For portable code the burden of selecting appropriately is on 
the folks including the headers. Otherwise just because it "works" in one valid 
toolchain does not mean it is guaranteed to work in another valid one.



gcc5 may well provide fewer of the optional declarations/definitions for some 
headers.


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

On 2015-Mar-16, at 08:37 PM, Mark Millard  wrote:

I tried "portmaster -tDK --no-confirm lang/clang36" on a powerpc (non-64):

$ freebsd-version -ku ; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG4C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Mon Mar  9 
22:24:27 PDT 2015 root@FBSDG4S0:/usr/obj/usr/srcC/sys/GENERICvtsc-NODEBUG  
powerpc powerpc

Again it used gcc5 to bootstrap, my having installed gcc5 recently, no other 
non-built-in-world compilers ever having been installed before. No clang of any 
kind to start with. Just gcc 4.2.1. No changes to lang/clang36. Just:

portmaster -tDK --no-confirm lang/clang36

Again it had the same MSVCToolChain.cpp problem:

llvm[4]: Compiling MSVCToolChain.cpp for Release build
MSVCToolChain.cpp: In member function 'bool 
clang::driver::toolchains::MSVCToolChain::getWindowsSDKDir(std::__cxx11::string&,
 int&, int&) const':
MSVCToolChain.cpp:215:5: error: '::sscanf' has not been declared
::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);
^

Like before when I had installed gcc5 it had no troubles installing and I made 
no changes.


I have another build test running where only built-in-world compilers existed 
(gcc 4.2.1 and clang 3.4.1). For this context "portmaster -tDK --no-confirm 
lang/clang36" initiated installing lang/gcc (i.e., 4.8.4 at this point) in 
order to provide itself with a compiler to bootstrap with. We will see how that 
one does. It takes longer since 2 compilers are being installed. (I started 
this one first but it is not done yet.)


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

On 2015-Mar-16, at 05:18 PM, Mark Millard  wrote:

Basic context (more context details listed later):

# freebsd-version -ku; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
19:23:14 PDT 2015 
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
powerpc powerpc64


The problem:

portmaster -tDK --no-confirm lang/clang36 is how I started the build.

The error reported was for in MSVCToolChain.cpp's member function:

bool clang::driver::toolchains::getWindowsSDKDir(std::__cxx1:string&,int&, 
int&) const

The report was:

MSVCToolChain.cpp:25:5: error: '::sscanf' has not been declared
::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);


I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. And it not being 
likely to be powerpc64 specific would be my guess. May be that it bootstrapped 
via gcc5? I've not yet tried from a powerpc (non-64) FreeBSD build.



Context details:

# svnlite info /usr/ports/lang/clang36
Path: lang/clang36
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
Relative URL: ^/head/lang/clang36
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 38029

Re: powerpc64 11.0-CURRENT portmaster lang/clang36 gets error: llvm-build: error: invalid native target: 'powerpc64' (not in project)

2015-03-16 Thread Mark Millard
The 2 powerpc (non-64) build attempts for clang 3.6 did not get this problem.

So this specific problem is powerpc64 specific.

Bootstrapping powerpc (non-64) clang 3.6 via gcc 4.8.4 (the current lang/gcc) 
works fine. (In absence of any c++ port lang/clang36 automatically installed 
lang/gcc (currently gcc 4.8.4) in order to bootstrap itself.)

Bootstrapping powerpc (non-64) clang 3.6 via gcc5 (by having lang/gcc5 already 
installed first) still reports an error for not declaring ::sscanf, just like 
powerpc64 based on gcc5 for bootstrapping did.

(This might be llvm/clang making use of only  where an include of 
 would be required to be involved in order to guarantee the :: 
(global) declaration/definition. The way the C++ standard (all vintages) is 
written gcc 4.8.4 and gcc5 could be this different and both be 
valid/conforming.)


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

On 2015-Mar-16, at 05:04 PM, Mark Millard  wrote:

Basic context (more context details listed later):

# freebsd-version -ku; uname -ap
11.0-CURRENT
11.0-CURRENT
FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r279514M: Wed Mar 11 
19:23:14 PDT 2015 
root@FBSDG4C0:/usr/obj/powerpc.powerpc64/usr/srcC/sys/GENERIC64vtsc-NODEBUG  
powerpc powerpc64


The problem:

portmaster -tDK --no-confirm lang/clang36 is how I started the build.

The error report was after it reported entering the directory:

/usr/obj/portswork/usr/ports/lang/clang36/work/llvm-3.6.0.src/tools/clang/lib/Driver/

The report was:

llvm-build: error: invalid native target: 'powerpc64' (not in project)


I'd be surprised if 11.0-CURRENT vs. 10.1-STABLE matters. But powerpc64 likely 
does. I've not yet tried from a powerpc (non-64) FreeBSD build.

I'll note that with top -PaSCHopid I watched it compile the PowerPc code 
generator software: it shoudl be able to handle PowerPCs fine.

My guess is a conversion of naming conventions is required someplace:

FreeBSD using powerpc64 vs. clang using ppc64. (Big endian context.)

This likely would matter for little endian naming as well (ppc64le on the clang 
end of things I expect). 




Context details:

# svnlite info /usr/ports/lang/clang36
Path: lang/clang36
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/clang36
Relative URL: ^/head/lang/clang36
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: brooks
Last Changed Rev: 380295
Last Changed Date: 2015-03-02 12:21:38 -0800 (Mon, 02 Mar 2015)

It used gcc5 to bootstrap as there was no clang present and that is the only 
gcc port installed:

# svnlite info /usr/ports/lang/gcc5
Path: lang/gcc5
Working Copy Root Path: /usr/ports
URL: https://svn0.us-west.freebsd.org/ports/head/lang/gcc5
Relative URL: ^/head/lang/gcc5
Repository Root: https://svn0.us-west.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 381120
Node Kind: directory
Schedule: normal
Last Changed Author: gerald
Last Changed Rev: 380943
Last Changed Date: 2015-03-10 10:00:25 -0700 (Tue, 10 Mar 2015)

# more /etc/make.conf
#CPP=clang-cpp
#CC=clang
#CXX=clang++
WRKDIRPREFIX=/usr/obj/portswork
#WITH_DEBUG=
MALLOC_PRODUCTION=


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


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