ted.
Currently outdated are OSVERSION < 1003000 (pre 10.3-RELEASE) and
110 <= OSVERSION < 1100122 (from 11-CURRENT'2013 to 11.0-PRERELEASE)
I expect these to be kept up to date with base system lifetimes,
be updated BEFORE removing any support for outdated release from
the tree and
t back the port version number in the
summary.
But I can not fix the assignee: it should not be
freebsd-powe...@freebsd.org
Can you put back the correct assignee for a port
problem?
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org ma
completely non-functional for powerpc64 (program crashes
via signals reporting problems).
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any m
B${CROSS_BINUTILS_PREFIX}
XCXXFLAGS+= -B${CROSS_BINUTILS_PREFIX}
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.
#
XCFLAGS+= -mcpu=cortex-a53
XCXXFLAGS+= -mcpu=cortex-a53
# There is no XCPPFLAGS but XCPP gets XCFLAGS content.
# more ~/src.configs/make.conf
CFLAGS.gc
[I add some what-it-take-for-an-upgrade information.]
On 2017-Mar-12, at 6:53 PM, Mark Millard wrote:
> Summary: RAM+(peak swap) was about 26 GiBytes.
> Also: about 118 GiByte /usr/obj/. . ./llvm40/ area.
> (2 processors, 2 cores each, all in use;
> WITH
On 2017-Mar-26, at 5:07 AM, Li-Wen Hsu wrote:
On Fri, Mar 24, 2017 at 11:31 AM, Mark Millard wrote:
> Building /usr/obj/pine64_clang/arm64.aarch64/usr/src/lib/libc/libc.so.7.full
> --- libc.so.7.full ---
> building shared library libc.so.7
> /usr/local/aarch64-freebsd/bin/ld: ge
On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
> 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 ru
On 2017-Mar-27, at 3:25 AM, Mark Millard wrote:
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>
>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
>>>
>>> I upgraded from llvm40 r4 to final. An interesting result was
>>> its creation
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 wrote:
>>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
> ...
>>>> Installed packages to be REMOVED:
&g
m the proper thread topic, feel free to change
> the
> subject line and respond to freebsd-ports if that is more appropriate, so I
> won't be accused of hijacking this thread.
Done.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-port
On 2017-Mar-29, at 8:53 AM, Brooks Davis wrote:
> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>>
>>> On 26 Mar 2017, at 23:36, Mark Millard wrote:
>>>>
>>>> I upgraded fr
did have a native-clang cross-compiler
involved.)
[I do not have access to server-class thread counts or
RAM either. And the non-multithread stages contribute
even in those contexts as well.]
So I'm not looking forward to the issue from that
point of view.
===
On 2017-Mar-30, at 1:22 PM, Mark Millard wrote:
> On 2017-Mar-29, at 8:53 AM, Brooks Davis wrote:
>
>> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
>>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric wrote:
>>>
>>>> On 26 Mar 2017, at
On 2017-Mar-30, at 7:51 PM, Mark Millard wrote:
> On 2017-Mar-30, at 1:22 PM, Mark Millard wrote:
>
>> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique
>> would not change the "WITNESS and INVARIANTS"-like part of the
>> issue. In fact if WITH_D
On 2017-Mar-31, at 4:51 PM, Mark Millard wrote:
> On 2017-Mar-30, at 7:51 PM, Mark Millard wrote:
>
>> On 2017-Mar-30, at 1:22 PM, Mark Millard wrote:
>>
>>> Sounds like the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG technique
>>> would not change the "
On 2017-Apr-1, at 3:51 AM, Mark Millard wrote:
> On 2017-Mar-31, at 4:51 PM, Mark Millard wrote:
>
>> On 2017-Mar-30, at 7:51 PM, Mark Millard wrote:
>>
>>> On 2017-Mar-30, at 1:22 PM, Mark Millard wrote:
>>>
>>>> Sounds like the ALLOW_OPTIM
o report for
installed-size for the no-WITH_DEBUG variant's scale
for installed-size.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
2
stable/11 is supposed to get an MFC for -r316679 in a couple
of weeks.
-r313772 was from February and has yet to be MFC'd but is needed.
No explicit MFC schedule has been set.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd
On 2017-Apr-10, at 12:12 PM, Mark Millard wrote:
> Context (on a BPI-M3 arm64 board):
I had been thinking of the BPI-M3 for other reasons
and typed that instead of the correct: pine64+ 2GB.
(True elsewhere as well.) I do really mean arm64
here.
> # svnlite info /usr/ports/ | grep &
On 2017-Apr-10, at 1:21 PM, John Marino wrote:
> On 4/10/2017 15:12, Mark Millard wrote:
>> On 2017-Apr-10, at 12:12 PM, Mark Millard wrote:
>>> with line 875 being the one with: @r=`${PWD_COMMAND}`
>>>
>>> It appears to me that the notation $${PWDCMD-p
On 2017-Apr-10, at 5:52 PM, Mark Millard wrote:
> On 2017-Apr-10, at 1:21 PM, John Marino wrote:
>
>> On 4/10/2017 15:12, Mark Millard wrote:
>>> On 2017-Apr-10, at 12:12 PM, Mark Millard wrote:
>>>> with line 875 being the one with: @r=`${PWD_COMMAND}`
>
/show_bug.cgi?id=214864
>
> ...
>
> --- Comment #16 from Pedro F. Giffuni ---
> (In reply to Mark Millard from comment #15)
> GCC has the nasty habit of "fixing" the system headers according to outdated
> expectations.
> There is a way to regenerate the headers but
trapping has more problems than just __nonnull
and __nonnull_all issues, at least for aarch64 head.
lang/gcc6-aux might not be the only thing with such issues.
I stopped with this. There could be more issues for lang/gcc6-aux .
===
Mark Millard
markmi at dsl-only.net
___
update claiming
native aarch64 support for synth and tried to build it. I've
no direct interest in lang/gcc6-aux . I just ended up with
FYI information about lang/gcc6-aux .]
===
Mark Millard
markmi at dsl-only.net
(I've added a missing "n" in the first "__nonnull_all&q
o prevent the fixincludes script from running:
sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in
(End quote)
So seems that disabling fixinc.sh's use is fairly common when
the headers are known to "not require fixing" (i.e., are known
to already be gcc compliant).
===
M
t wrote = write (descriptor, buffer, size);
^
The implicit-declaration warnings for read and write may well
also not be expected/desirable.
It may be that more than a script run is needed to make
things be appropriate.
===
Mark Millard
markmi at dsl-only.net
__
On 2017-Apr-14, at 6:54 PM, Mark Millard wrote:
> Alexander Kabaev kabaev at gmail.com on Sat Apr 15 00:20:40 UTC 2017
> wrote:
> . . .
>
>> it was suggested multiple times that the whole fixinc step is
>> ultimately harmful and serves no useful purpose and probably
I
wanted to explore.
I've seen material quoted from a exp-run that reported
that about 54(?) ports were then blocked by lang/gcc6-aux
not building. (So some problems might not be aarch64
specific despite my example context: the "54" material
was likely not for an aarch64 contex
On 2017-Apr-15, at 2:30 AM, Mark Linimon wrote:
> On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote:
>> I've seen material quoted from a exp-run that reported
>> that about 54(?) ports were then blocked by lang/gcc6-aux
>> not building.
>
> Althoug
${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
and use ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG= and WITH_DEBUG= :
# more /etc/make.conf
WANT_Q
On 2017-Apr-15, at 11:30 PM, Mark Millard wrote:
> On 2017-Apr-15, at 2:30 AM, Mark Linimon wrote:
>
>> On Fri, Apr 14, 2017 at 08:27:29PM -0700, Mark Millard wrote:
>>> I've seen material quoted from a exp-run that reported
>>> that about 54(?) ports were th
On 2017-Apr-16, at 1:10 AM, Mark Millard wrote:
> Context: amd64 FreeBSD -r316952 as a VirtualBox guest
> that was built using WITH_LLD_IS_LD= . ports -r438577.
>
> x11/xorg-minimal indirectly gets to devel/libunwind and
> devel/libunwind fails to build from source:
>
>
x: /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_FLAG
5697150-7ecd-e111-bb59-0022644237b5
Revision: 436731
Node Kind: directory
Schedule: normal
Last Changed Author: bdrewery
Last Changed Rev: 434651
Last Changed Date: 2017-02-22 15:33:44 -0800 (Wed, 22 Feb 2017)
===
Mark Millard
markmi at dsl-only.net
___
On 2017-Apr-16, at 7:01 PM, Ed Maste wrote:
> On 16 April 2017 at 04:10, Mark Millard wrote:
>> Context: amd64 FreeBSD -r316952 as a VirtualBox guest
>> that was built using WITH_LLD_IS_LD= . ports -r438577.
>>
>> x11/xorg-minimal indirectly gets to devel/libunwind a
3D
graphics or gaming. NEON can also accelerate signal processing algorithms
and functions to speed up applications such as audio and video processing,
voice and facial recognition, computer vision and deep learning.
===
Mark Millard
markmi at dsl-only.net
__
On 2017-May-5, at 11:28 AM, bob prohaska wrote:
> On Fri, May 05, 2017 at 09:30:39AM -0700, Mark Millard wrote:
>>
>> Wrong neon.
>>
>>
> Ahh, what I feared 8-)
>
>
>> https://developer.arm.com/technologies/neon says:
>>
>
> I di
On 2017-May-5, at 4:01 PM, bob prohaska wrote:
> On Fri, May 05, 2017 at 12:38:14PM -0700, Mark Millard wrote:
>>
>> An rpi2 has Cortex-A7 (armv7-A) cores that have NEON
>> but armv6 does not.
>>
>> There is some possibility that with something like
>&g
rget");
. . .
It appears that there is no kernel debugging
supported for TARGET_ARCH=powerpc currently.
(The system no longer has its own gdb related
materials.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
h
On 2017-May-6, at 5:21 PM, Mark Millard wrote:
> On:
>
> # uname -apKU
> FreeBSD FBSDG4S 12.0-CURRENT FreeBSD 12.0-CURRENT r317820M powerpc powerpc
> 1200030 1200030
>
> When I attempt to use:
>
> # which kgdb
> /usr/local/bin/kgdb
>
> that was from bu
[This update just notes that it appears that combination
${MK_GDB} == no && ${MK_GDB_LIBEXEC} == yes is not intended
to be used, effectively eliminating "THING #1" of 0-2.]
On 2017-May-6, at 10:03 PM, Mark Millard wrote:
> On 2017-May-6, at 5:21 PM, Mark Millard wrote:
>
[Mostly: Why THING #2 fails: checks for ET_EXEC
but the actual vmcore.* 's have ET_DYN instead.]
On 2017-May-8, at 11:30 AM, John Baldwin wrote:
> On Saturday, May 06, 2017 10:03:57 PM Mark Millard wrote:
>> THING #0:
>>
>> It appears that usr.sbin/crashinfo/crashin
[I've submitted bugzilla 219153 for this libvm issue of
not handling powerpc's/powerp64's ET_DYN vmcore.* 's and
such.]
On 2017-May-8, at 1:18 PM, Mark Millard wrote:
> [Mostly: Why THING #2 fails: checks for ET_EXEC
> but the actual vmcore.* 's have ET_DYN inst
looking at some vintage of config/rules.mk
on the web):
$(SOBJS):
$(REPORT_BUILD)
$(AS) -o $@ $(DEFINES) $(ASFLAGS) $($(notdir $<)_FLAGS)
$(LOCAL_INCLUDES) -c $<
then the -mcpu=cortex-a7 is likely not involved.
Instead such a context would suggest needing to supply
some o
On 2017-May-10, at 10:31 PM, Mark Millard wrote:
> On 2017-May-10, at 8:37 PM, bob prohaska wrote:
>
>> With freebsd at
>> FreeBSD www.zefox.com 12.0-CURRENT FreeBSD 12.0-CURRENT #50 r318138: Wed May
>> 10 10:30:51 PDT 2017 b...@www.zefox.com:/usr/obj/usr/src/sy
On 2017-May-11, at 6:44 PM, bob prohaska wrote:
> On Thu, May 11, 2017 at 01:53:33PM -0700, Mark Millard wrote:
>>
>> It would help others help you if the assembler or
>> compiler command that specifically generated this
>> error message was also included in the text
On 2017-May-11, at 7:16 PM, Mark Millard wrote:
> On 2017-May-11, at 6:44 PM, bob prohaska wrote:
>
>> On Thu, May 11, 2017 at 01:53:33PM -0700, Mark Millard wrote:
>>>
>>> It would help others help you if the assembler or
>>> compiler command tha
On 2017-May-12, at 12:31 PM, bob prohaska wrote:
> On Thu, May 11, 2017 at 08:14:14PM -0700, Mark Millard wrote:
>> Having -mcpu=cortex-a7 in ASFLAGS would contribute to
>> both of the examples.
>>
>
> Restarting the make with
> root@www:/usr/ports/www/firefox
On 2017-May-12, at 5:34 PM, bob prohaska wrote:
> On Fri, May 12, 2017 at 02:36:48PM -0700, Mark Millard wrote:
>>
>> My guess from the above is that the problem will
>> repeat in this rebuild.
>>
>>
>>
> That'
out
progressing to the ino64 changes in FreeBSD's
head (12-CURRENT).
Unfortunately ports-mgmt/synth suffers from
build prerequisites that do not have a wide
range of contributing maintainers or otherwise
broad support. This looks like it will make
ports-mgmt/synth problematical as things are
On 2017-May-30, at 1:06 PM, Mark Linimon wrote:
> On Tue, May 30, 2017 at 12:00:14PM -0700, Mark Millard wrote:
>> Kevin Oberman rkoberman at gmail.com wrote on Tue May 30 16:52:19 UTC 2017
>>
>>> I really suggest that you look at synth.
>
> synth is curren
builds
for DragonFly BSD. (DragonFly forked from FreeBSD back in FreeBSD-4.x
time frames.) So updates appropriate to FreeBSD's head driven by
just upstream activity would not seem likely.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@f
area: 10.x continues to get separate
lang/gcc* package builds from 11.x and later.
No problem for this context as far as I know.
Note: To simplify I choose to not be explicit
about what authors wrote what original text.
If that becomes an issue, it is correctable.
Blame me for
ng which specific handling needs to be made.
But the vm_ooffset_t and vm_pindex_t changes did not even
make the UPDATING notes. Right now things look to have
the worst combination for lang/gcc* when release/11.1.0/
becomes official: lang/gcc* 's break without notification
or suggestion of a workaro
l need whatever
technique is used. Some, such as lang/gcc6-aux, need
more done because of binary bootstrap materials being
downloaded and used and so the build of lang/gcc6-aux
gets the problem and fails before staging happens: the
binary-bootstrap materials need to avoid the adjusted
headers th
81000 0x1000>,
<0x01C82000 0x2000>,
<0x01C84000 0x2000>,
<0x01C86000 0x2000>;
interrupts = ;
};
I'll be trying 3 other u-boot-*'s so I may have more to
report later.
===
Mark Millard
mar...@d
On 2017-Jun-28, at 7:44 PM, Mark Millard wrote:
> Is the below a BSDL vs. GPL DTS issue?
>
> In my attempt to build sysutils/u-boot-pine64 I got:
>
> OBJCOPY u-boot.srec
> OBJCOPY u-boot-nodtb.bin
> start=$(aarch64-none-elf-nm u-boot | grep __rel_dyn_start | cut
On 2017-Jun-29, at 3:10 AM, Gerald Pfeifer wrote:
> Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard dsl-only.net>:
>> A primary test is building lang/gcc5-devel under release/11.0.1
>> and then using it under stable/11 or some draft of release/11.1.0 .
>
>
[It looks like USE_GCC=any is broken and leads to system-clang use.]
On 2017-Jun-29, at 5:58 PM, Gerald Pfeifer wrote:
> Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard
> :
>> I'm not currently set up to run more than head on
>> any of amd64, powerpc64, power
[Looks like output from "make test-gcc" is appropriate,
so I'm adding such.]
On 2017-Jul-2, at 7:53 PM, Mark Millard wrote:
> [It looks like USE_GCC=any is broken and leads to system-clang use.]
>
> On 2017-Jun-29, at 5:58 PM, Gerald Pfeifer wrote:
>
>> Am
[More on the behavior: it is more complicated than
previously shown.]
On 2017-Jul-2, at 8:12 PM, Mark Millard wrote:
> [Looks like output from "make test-gcc" is appropriate,
> so I'm adding such.]
>
> On 2017-Jul-2, at 7:53 PM, Mark Millard wrote:
>
>>
:
libc.so.7 => /lib/libc.so.7 (0x800825000)
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 447082
Last Changed Rev: 447082
===
Mark Millard
markmi at
o/openssl/crypto/ecdsa
/usr/src/crypto/openssl/crypto/engine /usr/src/crypto/openssl/crypto/err
/usr/src/crypto/openssl/crypto/evp /usr/src/crypto/openssl/crypto/hmac
/usr/src/crypto/openssl/crypto/idea /usr/src/crypto/openssl/crypto/kr
b5 /usr/src/crypto/openssl/crypto/lhash /usr/src/crypto/openssl/crypto/md4
/usr/src/crypto/openssl/crypto/md5 /usr/src/crypto/openssl/crypto/mdc2
/usr/src/crypto/openssl/crypto/modes /usr/src/crypto/openssl/crypto/objects
/usr/src/crypto/openssl/crypto/ocsp /usr/src/crypto/openssl/crypto/pem
/usr/src/crypto/openssl/crypto/pkcs12 /usr/src/crypto/openssl/crypto/pkcs7
/usr/src/crypto/openssl/crypto/pqueue /usr/src/crypto/openssl/crypto/rand
/usr/src/crypto/openssl/crypto/rc2 /usr/src/crypto/openssl/crypto/rc4
/usr/src/crypto/openssl/crypto/rc5 /usr/src/crypto/openssl/crypto/ripemd
/usr/src/crypto/openssl/crypto/rsa /usr/src/crypto/openssl/crypto/seed
/usr/src/crypto/openssl/crypto/sha /usr/src/crypto/openssl/crypto/srp
/usr/src/crypto/openssl/crypto/stack /usr/src/crypto/openssl/crypto/ts
/usr/src/crypto/openssl/crypto/txt_db /usr/src/crypto/openssl/crypto/ui
/usr/src/crypto/openssl/crypto/whrlpool /usr/src/crypto/openssl/crypto/x509
/usr/src/crypto/openssl/crypto/x509v3 /usr/src/secur
e/lib/libcrypto/man'
*** [secure/lib/libcrypto__L] Error code 2
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
mu-user-static are broken.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote:
> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
>> It appears that qemu-ppc64-static and qemu-ppc-static from
>> emulators/qemu-user-static are broken.
>
> Correct, and known for some time. (fwiw sparc64 h
On 2017-Aug-30, at 4:32 PM, Don Lewis wrote:
> On 30 Aug, Mark Millard wrote:
>> On 2017-Aug-30, at 4:00 AM, Mark Linimon wrote:
>>
>>> On Wed, Aug 30, 2017 at 03:09:40AM -0700, Mark Millard wrote:
>>>> It appears that qemu-ppc64-static and qemu-ppc-static
[Turns out that the emulated program counter is not progressing
for syscall emulation, at least for syscall falure cases.]
On 2017-Aug-30, at 8:43 PM, Mark Millard wrote:
> On 2017-Aug-30, at 4:32 PM, Don Lewis wrote:
>
>> On 30 Aug, Mark Millard wrote:
>>> On 2017-Aug
e PC is not
being adjusted now but needs to be adjusted.
===
Mark Millard
markmi at dsl-only.net
On 2017-Aug-31, at 12:13 PM, Mark Millard wrote:
[Turns out that the emulated program counter is not progressing
for syscall emulation, at least for [some] syscall [failure] cases.]
On 2017-Aug-30
[I show some of the target/ppc/translate.c source code
and related material this time. Not that I know enough
to patch it correctly.]
On 2017-Aug-31, at 12:13 PM, Mark Millard wrote:
> [Turns out that the emulated program counter is not progressing
> for syscall emulation, at least for
ORTED_VARS+= OPSYS
.if !defined(_OSRELEASE)
-_OSRELEASE!= ${UNAME} -r
+_OSRELEASE!= echo 12.0-CURRENT
.endif
_EXPORTED_VARS+= _OSRELEASE
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://li
On 2017-Sep-5, at 1:13 PM, Jan Beich wrote:
> Mark Millard writes:
>
>> In an experiment with building some arm ports via poudriere
>> cross building on amd64 I got the following. It appears that
>> clang does not handle all the assembler notation and a
>> differ
On 2017-Sep-5, at 1:33 PM, Mark Millard wrote:
> On 2017-Sep-5, at 1:13 PM, Jan Beich wrote:
>
>> Mark Millard writes:
>>
>>> In an experiment with building some arm ports via poudriere
>>> cross building on amd64 I got the following. It appears th
f the places:
# Get the operating system type
.if !defined(OPSYS)
-OPSYS!=${UNAME} -s
+OPSYS!=echo FreeBSD
.endif
_EXPORTED_VARS+=OPSYS
.if !defined(_OSRELEASE)
-_OSRELEASE!= ${UNAME} -r
+_OSRELEASE!= echo 12.0-CURRENT
.endif
_EXPORTED_VARS+=_OSRELEASE
=
ports of
the problem(s), noted as duplicates of the bugzilla that
has the patches at this point.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
/usr/src/sys/modules/armv8crypto/../Makefile.inc /usr/src/share/mk/bsd.own.mk
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk
/usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk
/usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk
/usr/src/share/mk/bs
[Looks like gcc7 might be causing its own problem
via a vec_step macro name in its altivec.h .]
On 2017-Sep-29, at 1:14 AM, Mark Millard wrote:
> I attempted a poudriere based build of some
> ports and the gcc7 build involved failed
> with the following sorts of notices:
>
>
Summary of later additions:
devel/powerpc64-gcc has the same problem as gcc7
in this clang-based powerpc64.
My note about using gcc 4.2.1 for the kernel
build was wrong. (My 32-bit powerpc builds
are that way, not the powerpc64 ones.)
On 2017-Sep-29, at 1:51 AM, Mark Millard wrote:
> [Lo
ARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
.endif
(Note: I've had problems with some ${UNAME} use returning empty strings,
which is why I've used echo as a replacement in places. The real point
for the above is the ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG use.)
===
Mar
2017-Sep-29, at 12:14 PM, Mark Millard wrote:
> Summary of later additions:
>
> devel/powerpc64-gcc has the same problem as gcc7
> in this clang-based powerpc64.
>
> My note about using gcc 4.2.1 for the kernel
> build was wrong. (My 32-bit powerpc builds
> are that way
*/
>
> +#if 0
> #if (defined macintosh || defined __POWERPC__ || defined __CFM68K__) && \
> !defined MAC && !defined MACOSX && !defined __BEOS__
> #define MAC
> +#endif
> #endif
>
> /*
===
Mark Millard
markmi at dsl-only.net
_
THOUT_GCC_IS_CC=
WITHOUT_GNUCXX=
#
NO_WERROR=
#
# Use WERROR to avoid stopping at the likes of:
# error: implicit conversion from 'int' to 'int8_t' (aka 'signed char') changes
value from 128 to -128 [-Werror,-Wconstant-conversion]
WERROR=
MALLOC_PRODUCT
correctly you are looking
more for (B) and (C) not being distinct.
Or am I wrong and you want(?):
(A) to be a amd64 (i386?) FreeBSD 11.1 context
(B) to be amd64(?) FreeBSD 12 for
cross compiling to aarch64 FreeBSD 12
and used to produce an aarch64 compiler
for use on aarch64 FreeBSD 12
On 2017-Oct-9, at 11:22 PM, Tarjei Jensen wrote:
>> On Mon, Oct 9, 2017 at 11:26 PM, Mark Millard wrote:
>> Tarjei Jensen tarjei99 at gmail.com wrote on
>> Mon Oct 9 17:16:41 UTC 2017 :
>>
>> > This does NOT concern making a cross compiler. It is about cross
6 2017
/usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool
Something like this might be involved in your context?
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
-mcpu=cortex-a7 (buildworld,
buildkernel, and ports builds).
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-uns
s for "make" can disagree. The one in
the environment in question needs to be consulted unless one
knows an alternate name as used in an alternate environment.
So many standards to choose from. . .
===
Mark Millard
markmi at dsl-only.net
_
rns EINVAL to
> indicate that the operation is not supported. (I think this is a strange
> choice of errno on the part of POSIX.)
>
> PR: 223383, 223440
> Reported by: Mark Millard
> Sponsored by: The FreeBSD Foundation
>
> Changes:
> _U stable/11/
>
T r325997M amd64 amd64
1200054 1200054
# more /etc/make.conf
WANT_QT_VERBOSE_CONFIGURE=1
#
DEFAULT_VERSIONS+=perl5=5.24 gcc=7
WRKDIRPREFIX?=/wrkdirs
#
# From a local /usr/ports/Mk/bsd.port.mk extension:
ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG=
#
.if ${.CURDIR:M*/devel/llvm*}
#WITH_DEBUG=
.elif ${.CURDI
usr/src/.cpignore ]; then
cpdup -i0 ${cpignore_flag} ${SRC_BASE} ${JAILMNT}/usr/src
SRC_BASE="${JAILMNT}/usr/src"
It leaves me wondering if some notation like:
${SRCPATH:-${JAILMNT}}/usr/src
should be in use in some places where
${JAILMNT}/usr/src
is now in use. I&#x
[Dumb typo in my } placements.]
On 2017-Nov-22, at 8:36 PM, Mark Millard wrote:
> As evidence only two lines of jail.sh reference SRCPATH
> other than where -S assigns to it:
>
> # grep "SRCPATH" /usr/local/share/poudriere/jail.sh
> [ -z "${SRCP
ut copies of such world builds on the
target device and used it with poudriere on that
device as well. Thus the BPI-M3 did not have to
do its own buildworld for poudriere use in its
jail when I tried local port builds via poudriere.
===
Mark Millard
markmi at dsl-only.net
___
.9 and later
• FreeBSD/amd64 Release 11 and later
• Linux/x86-64 (glib 2.6.32-based)
(I listed the contents of the 3 boxes
in right-box to left-box order.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing
err 1 "Cannot use / for -M"
fi
. . .
SRC_BASE="${JAILMNT}/usr/src"
case ${METHOD} in
. . .
null)
JAILFS=none
FCT=
;;
esac
On 2017-Dec-4, at 3:54 PM, Bryan Drewery wrote:
> On 12/3/2017 8:29 PM, Mark Millard wrote:
>> Note: /usr/ports/ (and so poudriere-devel) as of -r425204
>> (poudriere-devel-3.2.99.20171129).
>>
>> I expect that the below is from ports-mgmt/poudriere-=devel
>>
lite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 455204
Last Changed Rev: 455204
===
Mark Millard
markmi at dsl-only.net
___
src/sys/modules/dtb/allwinner/Makefile
M /usr/src/sys/powerpc/aim/mmu_oea64.c
M /usr/src/sys/powerpc/ofw/ofw_machdep.c
M /usr/src/sys/powerpc/powerpc/interrupt.c
M /usr/src/sys/powerpc/powerpc/mp_machdep.c
M /usr/src/sys/powerpc/powerpc/trap.c
r/lib/crtend.o /usr/lib/crtn.o
/tmp/cpp_atomic_64_test-1fa999.o: In function `main':
cpp_atomic_64_test.cpp:(.text+0xa8): undefined reference to `__atomic_load_8'
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
> On Tue, Dec 05, 2017 at 10:42:49AM -080
e of some other lang/gcc*'s: I just
happen to build lang/gcc7 but not the others (generally).
Context details:
# uname -apKU
FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT r326192M powerpc powerpc64
1200054 1200054
# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
R
sl/crypto/armcap.c:if (getauxval != NULL) {
/usr/src/crypto/openssl/crypto/armcap.c:if (getauxval(HWCAP) &
HWCAP_NEON) {
/usr/src/crypto/openssl/crypto/armcap.c:unsigned long hwcap =
getauxval(HWCAP_CE);
===
Mark Millard
markmi at dsl-only.net
___
0 0 0 100%/dev
(/dev/da0p1 has a UFS file system.)
# swapinfo
Device 1K-blocks UsedAvail Capacity
/dev/da0p2157286416876 1555988 1%
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@fre
101 - 200 of 544 matches
Mail list logo
