14 Jan 2015)
$ svnlite status ~markmi/src_10_1_releng/
M /home/markmi/src_10_1_releng/sys/ddb/db_main.c
M /home/markmi/src_10_1_releng/sys/ddb/db_script.c
M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofw_machdep.c
M /home/markmi/src_10_1_releng/sys/powerpc/ofw/ofwcall64.S
M /h
ep.c
sys/powerpc/ofw/ofw_machdep.c has a PowerMac G5 specific change to avoid
intermittent boot problems.
sys/ddb/... and sys/powerpc/ofw/ofwcall64.S are just to help me get evidence if
I do end up with another early-boot failure. DDB and GDB are listed in
sys/powerpc/conf/GENERIC64vtsc
up with another early-boot failure. DDB and GDB are listed in
sys/powerpc/conf/GENERIC64vtsc for the same reason.
sys/powerpc/powerpc/dump_machdep.c is from me forcing the DMA transfer size for
dumps to be small enough not to be rejected as too large of a DMA request size.
sys/powerpc/conf/G
e policy for trying to re-establish the
ports now that I can reliably boot the G5s.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-8, at 09:49 AM, Nathan Whitehorn wrote:
This works fine for me. Are you sure you don't have some weird configuration or
hardware problem?
-Nathan
O
36,10 @@
CONFIGURE_ARGS+=--enable-vdpau
.endif
+.if ${ARCH} == powerpc64
+CFLAGS+= -mminimal-toc
+.endif
+
post-patch:
@${REINPLACE_CMD} -e 's|-ffast-math|${FAST_MATH}|' -e 's|x86_64|amd64|'
\
${WRKSRC}/configure
===
Mark Millard
markmi at dsl-o
o get
back after that Xorg had died/quit. This was true for both vt and sc.
My X11 related powerpc (non-64) builds were stopped by...
"CXXLD mesa_dri_drivers.la" gets "c++: Internal error: Segmentation fault
(program ld)"
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar
primeEm+0x74> b 101761f8
<._ZN5cmsys15_stl_next_primeEm+0x84>
101761ec <._ZN5cmsys15_stl_next_primeEm+0x78> ld r9,112(r31)
101761f0 <._ZN5cmsys15_stl_next_primeEm+0x7c> ld r9,0(r9)
101761f4 <._ZN5cmsys15_stl_next_primeEm+0x80&
g the static on _get_stl_prime_list.) Once propagated the updates will
make KWSys and CMake's code again match in this area.
So eventually FreeBSD should pick up a fix that should allow WITH_DEBUG= to be
better behaved for CMake's programs that use it's hashtable.hxx .
===
Mark Millard
markmi at d
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 Milla
s
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/
nstallation 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'
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-C
ers. 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, M
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
aving
the only guaranteed-sufficient header explicitly included.
We will see what that shows.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-16, at 10:36 PM, Mark Millard wrote:
The last powerpc (non-64) build test to complete ran where only built-in-world
compilers originally existed
Please excuse all the "gcc491" references. It is lang/gcc49 and currently that
has 4.9.3 .
The gcc 4.9.1 in my head was from earlier powerpc64-xtoolchain-gcc experiments.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-17, at 02:19 AM, Mark Millard wrote:
On a powerpc (non-64)
guarantees to declare/define ::sscanf. But it should.
An alternative to the #include is to instead use std::sscanf notation. That
will be the next experiment to check if had been included somewhere or
not. It might be that neither header had been included.
===
Mark Millard
markmi at dsl-only.net
uot;llvm/ADT/StringExtras.h"
#include "llvm/Config/llvm-config.h"
#include "llvm/Option/Arg.h"
#include "llvm/Option/ArgList.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/FileSystem.h"
#include "llvm/Support/Process.h"
#inc
.h"
#include
// Include the necessary headers to interface with the Windows registry and
// environment.
...
if (!sdkVersion.empty())
std::sscanf(sdkVersion.c_str(), "v%d.%d", &major, &minor);
return hasSDKDir && !path.empty();
...
===
Mark Millard
mar
'mips' : 'Mips',
+ 'powerpc' : 'PowerPC',
++ 'powerpc64' : 'PowerPC',
+ 'sparc64' : 'Sparc',
+ 'x86' : 'X86'
e updated
> the copy within CMake:
>
> KWSys 2015-03-10 (4a698414)
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a427f86
>
> Merge branch 'upstream-kwsys' into update-kwsys
> http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e433223d
>
> -Brad
===
with different content but the same name are
appropriate. I renamed /usr/local/include/iconv.h to avoid it being an example
of that.
I will not list how I got powerpc64-xtoolchain-gcc (and so powerpc64-gcc) to
finish installing on a powerpc64 11.0-CURRENT.
===
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"
rpc
> -LDFLAGS+= -m elf32ppc_fbsd
> +LDFLAGS+= -melf32ppc_fbsd
> .endif
>
> .include "../Makefile.inc"
> Index: /usr/srcC/sys/boot/uboot/Makefile.inc
> =======
> --- /usr/srcC/sys/boot/uboot/
f clang building is not involved.
And the rest existed in my environment before I started this
powerpc64-xtoolchain-gcc exploration.
lib/libnv/test/dnv_tests.cc and lib/libnv/test/nv_tests.cc are from later than
the rest of the unmodified source code, teh rest being from...
# svnlite i
sr/include/c++/v1
> LDADD+=-L/usr/lib -lc++
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-18, at 09:28 PM, Mark Millard wrote:
Basic starting context:
> # freebsd-version -ku; uname -apKU
> 11.0-CURRENT
> 11.0-CURRENT
> FreeBSD FBSDG5C0 11.0-CURRENT FreeBSD 11.0-CURRENT
powerpc64-gcc (4.9.1) build, this
time including WITH_GCC_BOOTSTRAP= and WITH_GCC= and WITH_GNUCXX= but avoiding
their use.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freeb
Last Changed Author: dbn
> Last Changed Rev: 381120
> Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015)
I have gcc5 and clang36 ports installed. I made no use of clang36.
On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete its
installation because powerpc6
s-west.freebsd.org/ports
> Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
> Revision: 381120
> Node Kind: directory
> Schedule: normal
> Last Changed Author: dbn
> Last Changed Rev: 381120
> Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015)
I have gcc5 and c
; Path: /usr/ports
> Working Copy Root Path: /usr/ports
> URL: https://svn0.us-west.freebsd.org/ports/head
> Relative URL: ^/head
> 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: dbn
> Last Changed Rev: 381120
> Last Changed Date: 2015-03-12 10:13:39 -0700 (Thu, 12 Mar 2015)
I have gcc5 and clang36 ports installed. I've made no use of clang36.
On a powerpc64 11.0-CURRENT powerpc64-xtoolchain-gcc fails to complete its
installation because powerpc64-gcc fails to complete its installation. The
problems were 4 mismatched file names and one file also not put into staging. I
copied appropriate files to the missing names and place and from that status
the installation was able to continue and complete via postmaster with -C (as
long as powerpc64-gcc was not in use rebuilding itself: some other compiler was
in use for that activity instead).
===
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"
t 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 Auth
c deleted copy constructor fails similarly.)
in that both the original code and the improvement fail to compile the above
but instead treat it as an error. (Dimitry Andric tested the improvement and
https://llvm.org/bugs/show_bug.cgi?id=22771 shows the error that he got.)
===
Mark Millard
mark
irect or
indirect use of std::is_convertible. I do not know what criteria llvm/clang
uses for such issues.
===
Mark Millard
markmi at dsl-only.net
On 2015-Mar-22, at 09:56 PM, Mark Millard wrote:
I'd sent out a note Saturday for this for powerpc64-xtoolchain-gcc and its
powerpc64-gcc po
amd64 and arm.
>
> Best regards
> Michael
===
Mark Millard
markmi at dsl-only.net
Begin forwarded message:
From: Mark Millard
Subject: 11.0-CURRENT: SCTP_MAX_CWND, lib/libc/net/sctp_sys_calls.c -r279859
vs. updating to head snaphot -r280598
Date: 2015-March-26 at 07:36:01 PM PDT
f usage error, I don't know anything about the
> xtoolchain stuff. In any case, there doesn't seem to be anything wrong
> with the base build using the supported build mechanisms.
===
Mark Millard
markmi at dsl-only.net
Begin forwarded message:
Subject: 11.0-CURRENT: SBUF_INCLUDENU
d also
there seems to be a lack of bindings for various _restgpr__x compiler
support routines so boot1.elf fails to link. So I skipped that via
WITHOUT_BOOT= so I could see what WITH_LIB32= would do.
===
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"
k of
> int main()
> {
> return 0;
> }
produces something for which ./a.out segmentation faults in a way that neither
the system nor the port gdb can report on where.
For now it looks like I'm not going to have the time to work on figuring out
any of the issues involved.
7;s WCHAR_TYPE,
presuming gcc defaults are correct for FreeBSD as far as the type goes. It
might need a more explicit type to be sure of a Char match for that freebsd.h
file's context.)
The 4.9 vintages of powerpc64-gcc were messed up the same way, as was noted at
the time.
===
Mark Mi
uch a build actually works
for installworld and reboot.)]
> On 2015-Dec-6, at 2:44 PM, Andreas Tobler wrote:
>
> On 06.12.15 22:34, Mark Millard wrote:
>> [I picked the lists that I did because powerpc64-gcc is the external
>> toolchain created to allow modern powerpc64 builds.
[This is mostly a re-titling of an earlier freebsd-pcc/freebsd-toolchain
message to correctly identify the problem. I also added the freebsd-ports list
and some content.]
On 2015-Dec-15, at 4:36 AM, Konstantin Belousov wrote:
> On Mon, Dec 14, 2015 at 11:06:51PM -0800, Mark Millard wr
tall my ports?
[Justin: This gives an idea where I'm at relative to testing the Xorg/xfce4
failure on powerpc/GENERIC. buildworld, kernel, installworld seems to have
worked fine. But I do not have Xorg or xfce4 in place yet to repeat the
previously failing steps.]
===
Mark Millard
markmi a
mtree/BSD.gnome.dist in non-obvious contexts.)
===
Mark Millard
mar...@dsl-only.net
On Sep 7, 2014, at 3:24 PM, Mark Millard wrote:
It appears to me that if the portmaster man page's instructions for "Using
portmaster to do a complete reinstallation of all your ports" are still
supposed
BSDG5M1:~/fbsd_rebuild_materials # more /etc/make.conf
WITH_DEBUG_FILES=
WITHOUT_CLANG=
WRKDIRPREFIX=/usr/obj/portswork
WITH_DEBUG=
(Note: WITHOUT_CLANG is just because last I tried clang would not build for
WITH_DEBUG. And powerpc64/GENERIC64 does not use clang for
buildworld/buildkernel yet.)
Thanks much.
It may be a while before I get back to try this: I'm trying to build a
powerpc64/GENERIC64 11.0 kernel variant for an experiment for someone and the
PowerMac is busy doing that right now.
===
Mark Millard
markmi at dsl-only.net
On Nov 2, 2014, at 3:38 PM, Koop Mast
X1950 that vt mishandled
device sc
#device kbdmux # HACK: already listed by vt
options SC_OFWFB# OFW frame buffer
options SC_DFLT_FONT# compile font in
makeoptions SC_DFLT_FONT=cp437
===
Mark Millard
markmi at dsl-only.net
__
/py-sphinx
x11/resourceproto
security/sudo
archivers/unzip
multimedia/v4l_compat
lang/vala
x11/xcb-proto
x11/xcmiscproto
x11-drivers/xf86-video-scfb
x11-fonts/xf86bigfontproto
x11/xf86driproto
x11-wm/xfce4
textproc/xmlto
x11/xorg
devel/xorg-macros
archivers/zip
===
Mark Millard
markmi at dsl-only.ne
cess to for the PowerMac G5 (PCIExpress) context.
>
===
Mark Millard
markmi at dsl-only.net
Context note: I build a powerpc64/GENERIC64 variant with both vt and sc enabled
and use the same SSD for both NIVIDA based PowerMac G5's and one Radeon X1950
based one. Currently I do not use X11 at a
r/src/sys/boot/ofw/Makefile.inc
> M /usr/src/sys/boot/powerpc/Makefile
> M /usr/src/sys/boot/powerpc/Makefile.inc
> M /usr/src/sys/boot/uboot/Makefile.inc
> M /usr/src/sys/conf/Makefile.powerpc
> M /usr/src/sys/conf/kern.mk
> M /usr/src/sys/conf/kmod.mk
> ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG
> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc
> ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG
> ? /usr/src/sys/powerpc/conf/GENERICvtsc
> ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG
> M /usr/src/sys/powerpc/ofw/ofw_machdep.c
> M /usr/src/sys/powerpc/powerpc/exec_machdep.c
===
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 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
>
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:
>>
ibraries 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 gc
lint' (portlint-2.16.8) because a requisite
> package 'perl5-5.22.1_7' (lang/perl5.22) failed (specify -k to force)
ruby was still lang/ruby21 at the time.
I used portmaster instead and everything worked fine.
===
Mark Millard
markmi at dsl-only.net
__
t;
> /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/Configure.orig
> -L*|-R*|-Wl,-R*)
> xxx="-Wl,-R$shrpdir"
> /usr/obj/portswork/usr/ports/lang/perl5.22/work/perl-5.22.2/Configure.bak
> ccdlflags=' -Wl,-R/usr/local/lib/perl
gt; and proceeded usual rebuilding procedure.
>
> Fortunately, there was only 3 commits between r298836 and r298920,
> and I got right one in first attempt.
>
> But unfortunately, fixing portupgrade[-devel] or file/libmagic beyonds
> my hand. :-<
I have taken Tomoaki'
r example,
mess up the stack contents when signal delivery happens.
As far as I can tell depending on clang/clang++ for powerpc64 or for powerpc is
risky or requires analysis that things are actually working for all the
specific uses being made. But so far as I can tell clang 3.8.0 is an
improvemen
other things. -r299234 explicitly avoids calling
close(fd) when fd==STDIN_FILENO: The close would break the pipe in use by
portupgrade.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org
float for
11.0-CURRENT.
Of course until everyone updates to modern enough armv6 context a mix of
softfloat and hardfloat will be around.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailma
objcopy
OBJDUMP=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/objdump
RANLIB=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/ranlib
SIZE=/usr/local/${TOOLS_FROM_TYPE}-portbld-freebsd${VERSION_CONTEXT}/bin/size
#NO-SUCH:
STRINGS=/usr/local/${TOOL
On 2016-May-27, at 1:50 PM, Dimitry Andric wrote:
>
> On 27 May 2016, at 01:53, Mark Millard wrote:
>>
>> I do buildworld/buildkernel on a powerpc64 targeting itself via
>> lang/powerpc64-xtoolchain-gcc (a.k.a. lang/powerpc64-gcc for the most part).
>> [G
DD
EBUG=1 -DNEED_SOLARIS_BOOLEAN -MD -MF.depend.arc.o -MTarc.o
-std=iso9899:1999 -fstack-protector-strong -Wno-pointer-sign
-Wno-unknown-pragmas -Wno-empty-body -Wno-string-plus-int
-Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value
-Wno-parentheses-equality -Wno-unused-
/../../../contrib/llvm/tools/clang/include
>
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis
> .
>
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/include
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr
On 2016-May-27, at 6:04 PM, Mark Millard wrote:
> [Top posting failure results again.]
>
> -r300886 for powerpc64 failed for each of:
>
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/AnalysisDeclContext.cpp
>
> /usr/src/lib/cla
pt.
It looks like they have code to detect the attempt to use /usr and prevent it.
===
Mark Millard
markmi at dsl-only.net
On 2016-May-28, at 6:32 AM, Dimitry Andric wrote:
> On 28 May 2016, at 06:18, Mark Millard wrote:
> ...
>> The -r300886 powerpc64 devel/p
#ifndef __va_list__
> typedef __gnuc_va_list va_list;
> #endif /* not __va_list__ */
It would appear that
/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include/stdarg.h is the
one in use during the failure.
===
Mark Millard
markmi at dsl-only.net
__
On 2016-May-28, at 9:50 PM, Warner Losh wrote:
> On Wed, May 25, 2016 at 10:12 AM, Mark Millard wrote:
>> I'm not sure that Gerald or Brooks were CC'd on a report made to the arm
>> list about armv6 builds of gcc and llvm being broken now because of hard
>> fl
RAP=
> WITH_CLANG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITH
Just a quick top-posted note: lang/gcc5 (as of /usr/ports -r416711) built fine,
unlike the lang/gcc6 noted before/below. [I happened to try lang/gcc5 with the
bootstrap configuration item disabled.]
I may try lang/gcc6-devel to see what it does.
===
Mark Millard
markmi at dsl-only.net
On 2016
On 2016-Jun-12, at 5:43 PM, Mark Millard wrote:
> Just a quick top-posted note: lang/gcc5 (as of /usr/ports -r416711) built
> fine, unlike the lang/gcc6 noted before/below. [I happened to try lang/gcc5
> with the bootstrap configuration item disabled.]
>
> I may try lang/gc
ect-oriented interpreted scripting language
ruby22-bdb-0.6.6_4 Ruby interface to Oracle Berkeley DB revision 2
or later
sqlite3-3.13.0 SQL database engine in a C library
texinfo-6.1.20160425 Typeset documentation system with mult
required: no binary distributions are generally available for ports
for them.
===
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 &quo
ILP32 FreeBSD
architectures.
+- sscanf(optarg,"%lld",&kilobytes64);
++ sscanf(optarg,"%ld",&kilobytes64);
See the activity at:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211152
WWW: http://wiki.qemu.org/Main_Page
> Comment: QEMU CPU Emulator - development version
> Options:
> CDROM_DMA : on
> CURL : on
> DOCS : on
> GNS3 : on
> GNUTLS : on
> GTK2 : on
> JPEG : on
> OPENGL : on
> PCAP : on
> PNG: on
> SAMBA : off
> SASL : on
> STATIC_LINK: off
> USBREDIR : off
> X11: on
> X86_TARGETS: off
. . .
===
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"
-PRERELEASE #4 r304029M: Sat Aug 13
> 01:10:34 PDT 2016
> markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-N
> ODBG arm armv6 1100500 1100500
===
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"
d11.0/6.2.0/../../../../../armv6-portbld-freebsd11.0/bin/
> LIBRARY_PATH=/usr/local/lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/:/usr/local/lib/gcc6/gcc/armv6-portbld-freebsd11.0/6.2.0/../../../../../armv6-portbld-freebsd11.0/lib/:/usr/local/lib/gcc6/gcc/armv
> 6-portbld-freebsd11.0/6.2.
On 2016-Sep-1, at 7:46 AM, Mark Millard wrote:
> [I've only compared armv6 and amd64 behavior for this. amd64 did not get the
> problem.]
>
> The program is under 40 lines and is shown below:
> (It is a simplification of the context of the original discov
185
> #12 0x in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) thread 3
> [Switching to thread 3 (LWP 100270 of process 13188)]
> #0 thread_start (curthread=0x20812600) at
> /usr/src/lib/libthr/thread/thr_create.c:253
> 253
armv7a):
> #CFLAGS+= -march=armv7-a -mcpu=cortex-a7
> #CXXFLAGS+= -march=armv7-a -mcpu=cortex-a7
> #CPPFLAGS+= -march=armv7-a -mcpu=cortex-a7
> #
> #lang/gcc6's xgcc stage considers the above conflicting so use just:
> CFLAGS+= -mcpu=cortex-a7
> CXXFLAGS+= -mcpu=cortex-a7
On 2016-Sep-1, at 4:35 PM, Mark Millard wrote:
> Another top post because I should have kept going with the reductions: the
> following ~10 line program also shows the SIGSEGV behavior on armv6 (an rpi2)
> for running ./a.out after compiling via g++6.
>
>> # more g++6
ased buildworld for powerpc (with a gcc 4.2.1 based kernel with
signal delivery changes to deal with clang producing stack-handling ABI
violations). clang++ 3.8.0 for powerpc64 and powerpc has other problems,
including exception handling being messed up in the programs it produces.]
===
Mark Milla
rds,
>
> Curtis
>
>
>
> On 9/9/2016 4:32 PM, 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
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 f
2868 for devel/binutils with the text of the
list reports that I've quoted.
> 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.
>>
&
head/lang/gcc6-aux/Makefile :
LANGS= c c++ ada
. . .
.if ${OPSYS} == FreeBSD
ONLY_FOR_ARCHS= amd64 i386
. . .
.endif
.if ${OPSYS} == DragonFly
ONLY_FOR_ARCHS= x86_64
. . .
===
Mark Millard
markmi at dsl-only.net
___
freebs
more /etc/make.conf
> WANT_QT_VERBOSE_CONFIGURE=1
> #
> DEFAULT_VERSIONS+=perl5=5.22
> WRKDIRPREFIX=/usr/obj/portswork
> WITH_DEBUG=
> WITH_DEBUG_FILES=
> MALLOC_PRODUCTION=
> # svnlite status /usr/src
> M /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBui
Quick top post on avoiding the problem:
Reverting devel/powerpc64-gcc from -r421598 to -r413189 appears to have avoided
this problem.
While buildworld is still building: the build is well past the failure point
reported below.
===
Mark Millard
markmi at dsl-only.net
On 2016-Sep-26, at 4:48
rts
to llvm, for powerpc64 and for powerpc.
If projects/clang390-import also picks up these latest fixes ( -r282174 ,
-r283060 , -r283061 ) some interesting powerpc64 and powerpc experiments should
be possible. (But it will be around a couple of weeks before I've got access to
the powerpc6
cratch, you need to add -isystem /usr/include/c++/v1 *before* -isystem
> /usr/include. But it is better not to do this at all. :)
There is more background/supporting information in that comment.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-
On 2016-Oct-7, at 2:14 AM, O. Hartmann wrote:
>
> Am Fri, 7 Oct 2016 02:00:34 -0700
> Mark Millard schrieb:
>
>> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC
>> 2016 . . .
>>
>> . . . of having problems with not finding du
On 2016-Oct-7, at 2:34 AM, O. Hartmann wrote:
> Am Fri, 7 Oct 2016 02:00:34 -0700
> Mark Millard schrieb:
>
>> O. Hartmann ohartman at zedat.fu-berlin.de wrote on Fri Oct 7 08:26:27 UTC
>> 2016 . . .
>>
>> . . . of having problems with not finding durin
/auto/Authen/NTLM/.packlist
None of this had 5.24 equivalents present.
It appears that the UPDATING notes for portmaster are also incomplete.
Using portmaster with -f for each matching p5-*-* generally cleaned this up:
removing the 5.22 item and adding the 5.24 one. (There is no
/us
o
> 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?
(I normally only use explicitly version numbered lang/gcc* 's and
I use lang/gcc49 on powerpc64's.)
On 2016-Nov-25, at 5:00 PM, Dimitry Andric wrote:
> 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/chan
On 2016-Nov-25, at 11:47 PM, Gerald Pfeifer wrote:
> On Fri, 25 Nov 2016, Mark Millard wrote:
>> I wonder if that leaves lang/gcc and lang/gcc49 as conflicting.
>
> Yes, these two ports conflict for the time being, and are properly
> marked as such.
>
> (And I am lo
c6
automatically.
Now that devel/powerpc64-gcc is 6.2.0 based it and lang/gcc6 may also
conflict (I do not know yet: build in progress).
===
Mark Millard
markmi at dsl-only.net
Older material:
On 2016-Nov-26, at 4:16 PM, Mark Millard wrote:
> On 2016-Nov-25, at 11:47 PM, Gerald Pfeifer
On 2016-Dec-11, at 1:39 AM, Gerald Pfeifer wrote:
> Hi Mark,
>
> On Sat, 10 Dec 2016, Mark Millard wrote:
>> [Top post of example lack of lang/gcc6-devel vs. lan/gcc6
>> substitutability. Context /usr/ports/ at -r428325 (other
>> than a few specially controlled item
[After "BUILD_DEPENDS+= gcc6:lang/gcc6" below shows that
portmaster does not do what you indicate the build environment
should do. The beginning is not essential material.]
On 2016-Dec-11, at 4:40 AM, Gerald Pfeifer wrote:
> On Sun, 11 Dec 2016, Mark Millard wrote:
>> I re
On 2016-Dec-11, at 3:11 PM, Mark Linimon wrote:
> On Sun, Dec 11, 2016 at 02:59:36PM -0800, Mark Millard wrote:
>> I tend to have powerpc64 and powerpc patches because of my
>> experimenting with clang targeting them and that the standard
>> powerpc64 build does not boot P
is inference from the observed behavior
of existing code instead of from from reading
something indicating the intended properties.)
===
Mark Millard
markmi at dsl-only.net
On 2016-Dec-11, at 2:59 PM, Mark Millard wrote:
[After "BUILD_DEPENDS+= gcc6:lang/gcc6" below shows that
portmaster
oing anything where I depend on the
issues or distinctions. I just noted the quarterly
history that is available and where it happens to
exist --which may well be obvious to most folks
involved.)
===
Mark Millard
markmi at dsl-only.net
___
freebsd-ports
other
experiments I'm using portmaster for now and dealing with
whatever issues are involved.
At some point I may try poudriere in each of these environments.
But I may find that my context may just not be a good fit to the
main powerful tool, time preferences possibly being part of the
judg
On 2016-Dec-12, at 12:59 PM, Mark Millard wrote:
> [Top post asking if you (Gerald) think portmaster is in
> error and so if a bugzilla report should be made.]
>
> Do you expect that portmaster should instead/also(first)
> be checking (using the gcc6:lang/gcc6 related example
1 - 100 of 544 matches
Mail list logo
