Re: MOVED file on Current breaks portupgrade

[Kurt Jaeger]

Hi!

> Bad format in last entry of /usr/ports/MOVED breaks portupgrade:

Thanks, fixed in r413958.

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

MOVED file on Current breaks portupgrade

[Manfred Antar]

Bad format in last entry of /usr/ports/MOVED breaks portupgrade:

#portupgrade -av
/usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:118:in `block (2 levels) 
in fill': MOVED file format error (PortsDB::MOVEDError)
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:112:in `each'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:112:in 
`block in fill'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:111:in `open'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:111:in `fill'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:106:in 
`initialize'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:181:in `new'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/portsdb.rb:181:in 
`setup'
from /usr/local/lib/ruby/site_ruby/2.2/pkgtools/pkgtools.rb:242:in 
`init_pkgtools_global'
from /usr/local/sbin/portupgrade:531:in `block in main'
from /usr/local/lib/ruby/2.2/optparse.rb:917:in `initialize'
from /usr/local/sbin/portupgrade:238:in `new'
from /usr/local/sbin/portupgrade:238:in `main'
from /usr/local/sbin/portupgrade:2380:in `’

remove last line from MOVED it works again.
Manfred

___
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: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Steve Wills]

Hi,

On 04/24/16 10:16 AM, Mark Millard wrote:
> 
> For all the port update activity (including ruby) I used gcc49, 
> /etc/make.conf being:
> 
> # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES= 
> MALLOC_PRODUCTION=
> #
> #
> # For trying gcc49...
> # 
> CC=/usr/local/bin/gcc49
> CXX=/usr/local/bin/g++49 
> CPP=/usr/local/bin/cpp49
> . . . (binutils macros omitted here) . . .
> 
> 
> (I do not know if lang/gcc [or lang/gcc48] would work or not. I
> prefer a tool chain with a more modern C++ available but gcc49 is not
> yet what lang/gcc builds.)
> 
> 
> 
> I've seen notation like:
> 
> USE_GCC=4.9+
> 
> in port Makefiles. Also notation like:
> 
> .if ${ARCH} == powerpc64
> 
> and:
> 
> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
> 
> 
> So may be the extra notation in the Makefile(s) in question could be 
> something like:
> 
> # clang 3.8.0 and before is still broken in various ways for powerpc and 
> powerpc64:
> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
> USE_GCC=4.9+
> .endif
> 

Yep, this sounds right to me. I will test this with at least lang/ruby22
and lang/gcc6-devel when my current build finishes, or sooner if I get
impatient. :)


> I list both powerpc variants because powerpc and powerpc64 both have
> clang problems making buildworld a no-go by default and if gcc 4.2.1
> rejects a port for one it would normally also reject for the other.
> There may be other ${ARCH} values that would also be appropriate
> because they are also stuck at gcc 4.2.1 .

Makes sense.

> I do not claim to know necessary vs. sufficient status: more might be
> needed for some configurations (rpath issues? mixture of libraries
> compiled by distinct gcc's?). But I expect that the above should be
> better than being marked broken.

We'll find this out when we test! :)

Thanks,
Steve
___
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: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Mark Millard]

On 2016-Apr-24, at 5:58 AM, Steve Wills  wrote:
> 
> So lang/gcc6-devel builds fine using gcc49 (which builds fine and isn't
> currently marked broken. Can we patch the lang/gcc6-devel port so that
> it uses gcc49 when building on powerpc64?
> 
> Also, which compiler are you using for building ruby?
> 
> Steve

For all the port update activity (including ruby) I used gcc49, /etc/make.conf 
being:

# more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 
WRKDIRPREFIX=/usr/obj/portswork
WITH_DEBUG=
WITH_DEBUG_FILES= 
MALLOC_PRODUCTION=
#
#
# For trying gcc49...
# 
CC=/usr/local/bin/gcc49
CXX=/usr/local/bin/g++49 
CPP=/usr/local/bin/cpp49
. . . (binutils macros omitted here) . . .


(I do not know if lang/gcc [or lang/gcc48] would work or not. I prefer a tool 
chain with a more modern C++ available but gcc49 is not yet what lang/gcc 
builds.)



I've seen notation like:

USE_GCC=4.9+

in port Makefiles. Also notation like:

.if ${ARCH} == powerpc64

and:

.if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"


So may be the extra notation in the Makefile(s) in question could be something 
like:

# clang 3.8.0 and before is still broken in various ways for powerpc and 
powerpc64:
.if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
USE_GCC=4.9+
.endif

I list both powerpc variants because powerpc and powerpc64 both have clang 
problems making buildworld a no-go by default and if gcc 4.2.1 rejects a port 
for one it would normally also reject for the other. There may be other ${ARCH} 
values that would also be appropriate because they are also stuck at gcc 4.2.1 .

I do not claim to know necessary vs. sufficient status: more might be needed 
for some configurations (rpath issues? mixture of libraries compiled by 
distinct gcc's?). But I expect that the above should be better than being 
marked broken.

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


Older material:

On 04/24/16 03:19 AM, Mark Millard wrote:
> [A top-post of the results of my test build of lang/gcc6-devel using gcc49 to 
> do the build (until it switches over to xgcc). I do not have lang/gcc or 
> lang/gcc48 installed.]
> 
> lang/gcc6-devel's update built fine in my 
> powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a powerpc64 
> PowerMac. The options were as I normally use:
> 
>> # more /var/db/ports/lang_gcc6-devel/options
>> # This file is auto-generated by 'make config'.
>> # Options for gcc6-devel-6.0.0.s20160110
>> _OPTIONS_READ=gcc6-devel-6.0.0.s20160110
>> _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE JAVA MULTILIB
>> OPTIONS_FILE_UNSET+=BOOTSTRAP
>> OPTIONS_FILE_UNSET+=GRAPHITE
>> OPTIONS_FILE_UNSET+=JAVA
>> OPTIONS_FILE_UNSET+=MULTILIB
> 
> 
> I will note that ruby is implicitly in use in my environment and it too had 
> been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , and 
> lang/ruby23 all were so marked. (So I commented those marks out.)
> 
> My build that upgraded from ruby21 to ruby22 went fine.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Apr-23, at 5:21 PM, Mark Millard  wrote:
>> 
>> On 2016-Apr-23, at 4:17 PM, Steve Wills  wrote:
>>> 
>>> Hi,
>>> 
>>> On 04/23/16 05:50 PM, Mark Millard wrote:
 Recently a large block of ports (including lang/gcc6-devel) were
 marked in their Makefiles with
 
> BROKEN_powerpc64=   Does not build
 
 
 Does this only apply for use of gcc/g++ 4.2.1 or specific other
 verions? If so that is not the only way to have a powerpc64
 environment. For example: how "official" is use of
 devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and
 lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)? 
>>> 
>>> 
>>> The intent was just that they don't build with the default config, ie,
>>> gcc 4.2.1 from base. If there are ways to make things build with other
>>> compilers, we should look at getting those changes into ports.
>>> 
>>> You can find the logs of the build that I based all those changes on here:
>>> 
>>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default=2016-04-02_20h57m16s
>>> 
>>> Specifically the gcc6-devel one is here:
>>> 
>>> http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log
>>> 
>>> Though I realize now that was simply a timeout and perhaps shouldn't
>>> have been marked as broken. A few of the llvm ones timed out and I
>>> didn't mark those as broken and meant to not mark any that timed out as
>>> broken, and to go back and retry them, but didn't notice this one was a
>>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it
>>> builds for you.
>> 
>> Since my original note -r413919 has updated devel/gcc6-devel. So I'll end up 
>> testing that update once I get to that point.
>> 
>> I'll note that the svn-ports-head entry for -r412746 lists several llvm 
>> items:
>> 
>> 

Re: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Steve Wills]

So lang/gcc6-devel builds fine using gcc49 (which builds fine and isn't
currently marked broken. Can we patch the lang/gcc6-devel port so that
it uses gcc49 when building on powerpc64?

Also, which compiler are you using for building ruby?

Steve

On 04/24/16 03:19 AM, Mark Millard wrote:
> [A top-post of the results of my test build of lang/gcc6-devel using gcc49 to 
> do the build (until it switches over to xgcc). I do not have lang/gcc or 
> lang/gcc48 installed.]
> 
> lang/gcc6-devel's update built fine in my 
> powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a powerpc64 
> PowerMac. The options were as I normally use:
> 
>> # more /var/db/ports/lang_gcc6-devel/options
>> # This file is auto-generated by 'make config'.
>> # Options for gcc6-devel-6.0.0.s20160110
>> _OPTIONS_READ=gcc6-devel-6.0.0.s20160110
>> _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE JAVA MULTILIB
>> OPTIONS_FILE_UNSET+=BOOTSTRAP
>> OPTIONS_FILE_UNSET+=GRAPHITE
>> OPTIONS_FILE_UNSET+=JAVA
>> OPTIONS_FILE_UNSET+=MULTILIB
> 
> 
> I will note that ruby is implicitly in use in my environment and it too had 
> been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , and 
> lang/ruby23 all were so marked. (So I commented those marks out.)
> 
> My build that upgraded from ruby21 to ruby22 went fine.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Apr-23, at 5:21 PM, Mark Millard  wrote:
>>
>> On 2016-Apr-23, at 4:17 PM, Steve Wills  wrote:
>>>
>>> Hi,
>>>
>>> On 04/23/16 05:50 PM, Mark Millard wrote:
 Recently a large block of ports (including lang/gcc6-devel) were
 marked in their Makefiles with

> BROKEN_powerpc64=   Does not build


 Does this only apply for use of gcc/g++ 4.2.1 or specific other
 verions? If so that is not the only way to have a powerpc64
 environment. For example: how "official" is use of
 devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and
 lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)? 
>>>
>>>
>>> The intent was just that they don't build with the default config, ie,
>>> gcc 4.2.1 from base. If there are ways to make things build with other
>>> compilers, we should look at getting those changes into ports.
>>>
>>> You can find the logs of the build that I based all those changes on here:
>>>
>>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default=2016-04-02_20h57m16s
>>>
>>> Specifically the gcc6-devel one is here:
>>>
>>> http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log
>>>
>>> Though I realize now that was simply a timeout and perhaps shouldn't
>>> have been marked as broken. A few of the llvm ones timed out and I
>>> didn't mark those as broken and meant to not mark any that timed out as
>>> broken, and to go back and retry them, but didn't notice this one was a
>>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it
>>> builds for you.
>>
>> Since my original note -r413919 has updated devel/gcc6-devel. So I'll end up 
>> testing that update once I get to that point.
>>
>> I'll note that the svn-ports-head entry for -r412746 lists several llvm 
>> items:
>>
>>  head/devel/llvm-cheri/Makefile
>>  head/devel/llvm-devel/Makefile
>>  head/devel/llvm33/Makefile
>>  head/devel/llvm34/Makefile
>>  head/devel/llvm38/Makefile
>>
>> But I do not build any of those normally. llvm38 likely is toolchain vintage 
>> dependent for if it builds or not. Others may be as well.
>>
>>> Also note that build was using the 2016Q2 branch, but the
>>> BROKEN_powerpc64 was committed to the main branch. Perhaps that change
>>> should be merged to the 2016Q2 branch.
>>>
>>> Anyway, I'm currently retrying the build, after fixing pixman and
>>> merging that to the 2016Q2 and then locally patching in the
>>> BROKEN_powerpc64 things into my local tree. You can see the progress of
>>> that here:
>>>
>>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default=2016-04-21_17h38m55s
>>>
>>>
 Can broken be marked for only specific tool chains?

>>>
>>> Not trivially, but it's probably doable somehow.
>>>
> # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU 
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M:
> Sat Apr  9 22:22:19 PDT 2016
> root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG
> powerpc 1100105 1100105

 For the rest of this note I'll focus on lang/gcc-devel since I happen
 to build and install it.

> # pkg info '*gcc*' gcc49-4.9.4.s20160406 
> gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0 
> powerpc64-xtoolchain-gcc-0.1

 gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on the
 that same old PowerMac. -r413188 is the prior lang/gcc-devel check in
 before being marked broken for 

Re: Making a port - debugging cmake check_include_file

[abi]

You mean that the checks are passed, but actual support of V4L - is not?
V4L is the optional feature, so lack of it is not a critical error. From 
what I see in cmake files is that header files are detected and several 
knobs are set.
Should I check that these headers somehow used ? I don't have local or 
analog video cameras :(
Or, assuming that if header files are detected and included, failure to 
include them in compilation phase will lead to fatal error, I shouldn't 
bother?


On 24.04.2016 12:59, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 12:48:58PM +0300 I heard the voice of
abi, and lo! it spake thus:

I passed -DCMAKE_REQUIRED_INCLUDES:STRING="${LOCALBASE}/include" from
port Makefile.
Looks like the best solution - no need to poke upstream or make patch.

Interesting.  It's not clear from the docs that
CMAKE_REQUIRED_INCLUDES affects the actual build of the program (or
anything except the check_include_file() from a look around,
actually).  Well, if it works...




___
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: Making a port - debugging cmake check_include_file

[Matthew D. Fuller]

On Sun, Apr 24, 2016 at 12:48:58PM +0300 I heard the voice of
abi, and lo! it spake thus:
>
> I passed -DCMAKE_REQUIRED_INCLUDES:STRING="${LOCALBASE}/include" from 
> port Makefile.
> Looks like the best solution - no need to poke upstream or make patch.

Interesting.  It's not clear from the docs that
CMAKE_REQUIRED_INCLUDES affects the actual build of the program (or
anything except the check_include_file() from a look around,
actually).  Well, if it works...


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

Re: Making a port - debugging cmake check_include_file

[abi]

I passed -DCMAKE_REQUIRED_INCLUDES:STRING="${LOCALBASE}/include" from 
port Makefile.

Looks like the best solution - no need to poke upstream or make patch.

On 24.04.2016 12:43, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 12:09:53PM +0300 I heard the voice of
abi, and lo! it spake thus:

On 24.04.2016 12:00, Matthew D. Fuller wrote:

  get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
INCLUDE_DIRECTORIES)
  set(CMAKE_REQUIRED_INCLUDES ${idirs})

seems like it might do the trick.

Nope, the same behavior.

Did you add those along with and after the EXTRA_INCDIRS stuff?  Else
the extra bits wouldn't have been stuck into INCLUDE_DIRECTORIES yet.



Is hardcoded directory includes considered evil and I should find
(read - ask here :)) ) better solution ?

LOCALBASE != /usr/local is liable to be pretty rare, but I think it's
still theoretically supported, so...




___
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: Making a port - debugging cmake check_include_file

[Matthew D. Fuller]

On Sun, Apr 24, 2016 at 12:09:53PM +0300 I heard the voice of
abi, and lo! it spake thus:
> On 24.04.2016 12:00, Matthew D. Fuller wrote:
> >  get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
> > INCLUDE_DIRECTORIES)
> >  set(CMAKE_REQUIRED_INCLUDES ${idirs})
> >
> > seems like it might do the trick.
>
> Nope, the same behavior.

Did you add those along with and after the EXTRA_INCDIRS stuff?  Else
the extra bits wouldn't have been stuck into INCLUDE_DIRECTORIES yet.


> Is hardcoded directory includes considered evil and I should find
> (read - ask here :)) ) better solution ?

LOCALBASE != /usr/local is liable to be pretty rare, but I think it's
still theoretically supported, so...


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

Re: Making a port - debugging cmake check_include_file

[abi]

Nope, the same behavior.
ZM has OS detection block, I added there
set(CMAKE_REQUIRED_INCLUDES "/usr/include" "/usr/local/include") if 
system is BSD.


Now I have
-- Looking for libv4l1-videodev.h
-- Looking for libv4l1-videodev.h - found
-- Looking for linux/videodev2.h
-- Looking for linux/videodev2.h - found

and tests are passed/entire project is builded. Is hardcoded directory 
includes considered evil and I should find (read - ask here :)) ) better 
solution ?


On 24.04.2016 12:00, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 11:44:31AM +0300 I heard the voice of
abi, and lo! it spake thus:

I go the first way, however it seems that include directory is ignored
in include tests.

Oh, right.  That's annoying.



Should I try CMAKE_REQUIRED_INCLUDES ? However, I don't know the
effect of this on linux systems.

I'd skip worrying about that for now.  Get a patch working for the
port, then worry later about if/how to upstream it.

 get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
INCLUDE_DIRECTORIES)
 set(CMAKE_REQUIRED_INCLUDES ${idirs})

seems like it might do the trick.




___
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: Making a port - debugging cmake check_include_file

[Matthew D. Fuller]

On Sun, Apr 24, 2016 at 11:44:31AM +0300 I heard the voice of
abi, and lo! it spake thus:
>
> I go the first way, however it seems that include directory is ignored 
> in include tests.

Oh, right.  That's annoying.


> Should I try CMAKE_REQUIRED_INCLUDES ? However, I don't know the
> effect of this on linux systems.

I'd skip worrying about that for now.  Get a patch working for the
port, then worry later about if/how to upstream it.

get_property(idirs DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} PROPERTY 
INCLUDE_DIRECTORIES)
set(CMAKE_REQUIRED_INCLUDES ${idirs})

seems like it might do the trick.


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

Re: Failure compiling java/openjdk8

[Matthias Andree]

Am 23.04.2016 um 12:02 schrieb Willem Offermans:
> Dear FreeBSD friends,
> 
> In my attempt to juvenile an old FreeBSD beast, I encountered another 
> hurdle: a failure compiling java/openjdk8
> 
> 
> gmake[4]: Leaving directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make'
> gmake[4]: Entering directory '/usr/ports/java/openjdk8/work/openjdk/jdk/make'
> Compiling 9455 files for BUILD_JDK
> Killed
> gmake[4]: *** 
> [/usr/ports/java/openjdk8/work/openjdk/build/bsd-x86-normal-server-release/jdk/classes/_the.BUILD_JDK_batch]
>  Error 137

That Error 137 is "signal 9 (SIGKILL)" and added 128 for "core dump
requested". Typically an indication of a last-resort cleanup by the kernel.

Has the machine run out of memory during the compile?

Can you reduce the number of CPU cores used for the compile, in an
attempt to reduce RAM usage?
___
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: Making a port - debugging cmake check_include_file

[abi]

I go the first way, however it seems that include directory is ignored 
in include tests.

-- Found PkgConfig: /usr/local/bin/pkg-config (found version "0.28")
-- Checking for module 'libv4l1'
--   Found libv4l1, version 1.6.3

gmake[3]: Entering directory 
'/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_c7b01.dir/CheckIncludeFile.c.o
/usr/bin/cc-O2 -pipe  -fstack-protector -fno-strict-aliasing -o 
CMakeFiles/cmTC_c7b01.dir/CheckIncludeFile.c.o   -c 
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c
/usr/home/abishai/zoneminder/work/ZoneMinder-5a3978f/CMakeFiles/CMakeTmp/CheckIncludeFile.c:1:10: 
fatal error: 'libv4l1-videodev.h' file not found

#include 

No -I, like before.
Should I try CMAKE_REQUIRED_INCLUDES ? However, I don't know the effect 
of this on linux systems.



On 24.04.2016 10:13, Matthew D. Fuller wrote:

On Sun, Apr 24, 2016 at 01:28:35AM +0300 I heard the voice of
abi, and lo! it spake thus:

Thanks!
If speak about general purpose solution, acceptable by upstream, I should
1. make cmake variable like INCLUDE_DIR_EXTRA
2. if set, include it contents.
3. add default value if platform is FreeBSD
Am I right?

I'd say it depends on how much work you wanna put in, and how
interested upstream is.


The pkgconfig path is fairly simple.  In a quick test:

 include(FindPkgConfig)
 pkg_check_modules(LIBV4L1 libv4l1)
 if(LIBV4L1_FOUND)
 include_directories(${LIBV4L1_INCLUDE_DIRS})
 endif()

seems to set things right here (I assume from the libv4l1-videodev.h
that it wants v4l_1_ rather than v4l_2_).  That may be trivially
upstreamable, since it should just quietly have no effect in the cases
where v4l isn't in pkgconf, and DTRT when it is.  Of course, it won't
work if a system doesn't have pkg-config installed, so unless you
wanted to add that as a build dep (it _is_ pretty tiny, but it's an
extra dep), you couldn't assume it was there on the system.


A somewhat more verbose solution that passes more control to the port
level would be to patch in a block like

 if(EXTRA_INCDIRS)
 foreach(dir ${EXTRA_INCDIRS})
 include_directories(${dir})
 endforeach()
 endif()

relatively early into the CMakeLists.txt and then add $LOCALBASE into
the cmake command with something like

 CMAKE_ARGS+=-DEXTRA_INCDIRS="${LOCALBASE}"

in the port Makefile (untested).  Aside from potential need to redo
the patch if the CMakeLists.txt changes between releases, that doesn't
really need any upstream involvement at all, it can just be carried in
the port.  OTOH, it's probably not too objectionable (possibly with
tweaks to variable naming) to upstream either.





___
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: port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Mark Millard]

[A top-post of the results of my test build of lang/gcc6-devel using gcc49 to 
do the build (until it switches over to xgcc). I do not have lang/gcc or 
lang/gcc48 installed.]

lang/gcc6-devel's update built fine in my 
powerpc64-xtoolchain-gcc/powerpc64-gcc and gcc49 environment on a powerpc64 
PowerMac. The options were as I normally use:

> # more /var/db/ports/lang_gcc6-devel/options
> # This file is auto-generated by 'make config'.
> # Options for gcc6-devel-6.0.0.s20160110
> _OPTIONS_READ=gcc6-devel-6.0.0.s20160110
> _FILE_COMPLETE_OPTIONS_LIST=BOOTSTRAP GRAPHITE JAVA MULTILIB
> OPTIONS_FILE_UNSET+=BOOTSTRAP
> OPTIONS_FILE_UNSET+=GRAPHITE
> OPTIONS_FILE_UNSET+=JAVA
> OPTIONS_FILE_UNSET+=MULTILIB


I will note that ruby is implicitly in use in my environment and it too had 
been marked as broken for powerpc64: lang/ruby21 , lang/ruby22 , and 
lang/ruby23 all were so marked. (So I commented those marks out.)

My build that upgraded from ruby21 to ruby22 went fine.

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

On 2016-Apr-23, at 5:21 PM, Mark Millard  wrote:
> 
> On 2016-Apr-23, at 4:17 PM, Steve Wills  wrote:
>> 
>> Hi,
>> 
>> On 04/23/16 05:50 PM, Mark Millard wrote:
>>> Recently a large block of ports (including lang/gcc6-devel) were
>>> marked in their Makefiles with
>>> 
 BROKEN_powerpc64=   Does not build
>>> 
>>> 
>>> Does this only apply for use of gcc/g++ 4.2.1 or specific other
>>> verions? If so that is not the only way to have a powerpc64
>>> environment. For example: how "official" is use of
>>> devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc as well) and
>>> lang/gcc49 used on a powerpc64 box (in my case an old PowerMac)? 
>> 
>> 
>> The intent was just that they don't build with the default config, ie,
>> gcc 4.2.1 from base. If there are ways to make things build with other
>> compilers, we should look at getting those changes into ports.
>> 
>> You can find the logs of the build that I based all those changes on here:
>> 
>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default=2016-04-02_20h57m16s
>> 
>> Specifically the gcc6-devel one is here:
>> 
>> http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-02_20h57m16s/logs/errors/gcc6-devel-6.0.0.s20160320.log
>> 
>> Though I realize now that was simply a timeout and perhaps shouldn't
>> have been marked as broken. A few of the llvm ones timed out and I
>> didn't mark those as broken and meant to not mark any that timed out as
>> broken, and to go back and retry them, but didn't notice this one was a
>> timeout. We can remove the BROKEN_powerpc64 from lang/gcc-devel if it
>> builds for you.
> 
> Since my original note -r413919 has updated devel/gcc6-devel. So I'll end up 
> testing that update once I get to that point.
> 
> I'll note that the svn-ports-head entry for -r412746 lists several llvm items:
> 
>  head/devel/llvm-cheri/Makefile
>  head/devel/llvm-devel/Makefile
>  head/devel/llvm33/Makefile
>  head/devel/llvm34/Makefile
>  head/devel/llvm38/Makefile
> 
> But I do not build any of those normally. llvm38 likely is toolchain vintage 
> dependent for if it builds or not. Others may be as well.
> 
>> Also note that build was using the 2016Q2 branch, but the
>> BROKEN_powerpc64 was committed to the main branch. Perhaps that change
>> should be merged to the 2016Q2 branch.
>> 
>> Anyway, I'm currently retrying the build, after fixing pixman and
>> merging that to the 2016Q2 and then locally patching in the
>> BROKEN_powerpc64 things into my local tree. You can see the progress of
>> that here:
>> 
>> http://poudriere.mouf.net/karl/poudriere/build.html?mastername=headpowerpc-default=2016-04-21_17h38m55s
>> 
>> 
>>> Can broken be marked for only specific tool chains?
>>> 
>> 
>> Not trivially, but it's probably doable somehow.
>> 
 # freebsd-version -ku 11.0-CURRENT 11.0-CURRENT # uname -aKU 
 FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT #29 r297769M:
 Sat Apr  9 22:22:19 PDT 2016
 root@FBSDG5C0:/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG
 powerpc 1100105 1100105
>>> 
>>> For the rest of this note I'll focus on lang/gcc-devel since I happen
>>> to build and install it.
>>> 
 # pkg info '*gcc*' gcc49-4.9.4.s20160406 
 gcc6-devel-6.0.0.s20160410 powerpc64-gcc-5.3.0 
 powerpc64-xtoolchain-gcc-0.1
>>> 
>>> gcc6-devel-6.0.0.s20160410 was built from -r413230 svn source on the
>>> that same old PowerMac. -r413188 is the prior lang/gcc-devel check in
>>> before being marked broken for powerpc64. For how I build it was not
>>> broken at the time.
>>> 
>>> I historically use devel/powerpc64-xtoolchain-gcc (so
>>> devel/powerpc64-gcc as well) for the so-called "cross build" stages
>>> of buildworld/buildkernel (11.0-CURRENT). (I also do true cross
>>> builds for TARGET_ARCH=powerpc64 from an amd64 context sometimes.)
>>> 
>>> gcc 4.2.1 is not present before, during, or after on the