FreeBSD ports you maintain which are out of date
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 +-+ net-mgmt/ocsinventory-agent | 2.4.2 | v2.6.0 +-+ 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 https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
RE: maintenance of gcc cross ports
What do you think of updating the bare metals to 9.1.0? I don’t know anything outside of U-Boot and the PSCI Monitor (rpi-firmware) that actually depends on those ports and I've tested them with my custom ports. The powerpc64-gcc patches aren't needed to build the bare metal ports. Neither port has listed maintainers. I am willing to maintain them if no one else wants to. I managed to get U-Boot to build without GCC but it was a tremendous effort and required a lot of patches. I've submitted some patches to the U-Boot team but I don't think they're going to accept them. Bug report for regular expression issues is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237982 - James Shuriff -Original Message- From: John Baldwin Sent: Monday, May 20, 2019 4:45 PM To: James Shuriff ; Mark Millard Cc: ports-list freebsd ; b...@freebsd.org Subject: Re: maintenance of gcc cross ports I do think it probably makes sense to divorce the baremetal GCC ports from powerpc64-gcc and let powerpc64-gcc just be the basis for FreeBSD-specific toolchains. On 5/19/19 10:48 AM, James Shuriff wrote: > I have a Raspberry Pi 3 model b. I use the LLVM toolchain to build the system > but the GNU toolchain is required to build U-Boot. U-Boot uses global > register variables and LLVM doesn't support this. sysutils/u-boot-pine64 does > use aarch64-none-elf-gcc, for the same reason. The family is allwinner64 and > that's set to use aarch64-none-elf-gcc. Here is an article explaining the > feature U-Boot uses that's not in LLVM (the reason GNU is required for > building it): > > https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html > > Aarch64 is a Tier 2 architecture. The toolchain should have an active > maintainer (the maintainer is listed as po...@freebsd.org). I've opened a bug > report for the bugs in the Makefile. We should be using a newer toolchain or > separate arm-none-eabi and aarch64-none-elf from powerpc64. I am guessing the > Makefile bugs occurred because the original designer didn't intend on > powerpc64-gcc being used for targets like arm-none-eabi and aarch64-none-elf. > The patches you pointed out before don't even have any effect on the bare > metal ports. The arm and aarch64 bare metal ports are the oddballs in the > group. The difference being: powerpc64-gcc, aarch64-gcc, amd64-gcc, i386-gcc, > mips*-gcc, and sparc64-gcc are all intended for, as you said Mark, alternate > toolchain work with FreeBSD. These are not the official toolchains for > FreeBSD and I can see why they don't have the same level of care as the > official toolchain. But the side effect of this is arm-none-eabi-gcc and > aarch64-none-elf-gcc receive the same level of support, though they are > *required* to build most FreeBSD systems on those platforms. > > - James Shuriff > > -Original Message- > From: Mark Millard > Sent: Sunday, May 19, 2019 11:46 AM > To: James Shuriff > Cc: ports-list freebsd ; b...@freebsd.org; > j...@freebsd.org > Subject: Re: maintenance of gcc cross ports > > > > On 2019-May-19, at 07:40, James Shuriff wrote: > >> I didn't/don't plan on touching binutils. Binutils is okay. I made new >> patches as well. What I'm really concerned with bringing up to date is >> aarch64-none-elf-gcc. > >> The GNU toolchain is unfortunately required for building an Aarch64 >> system > > Are you specifically referencing contexts that need to build u-boot? > (My guess is: yes.) > > I've done buildworld buildkernel based on system clang and lld many > times in the past, though not very recently. (I currently do not have > access to the environment but will again, eventually.) > > For aarch64 I'd mostly recently built for and used: > > A) a Pine64+ 2GB (needs: sysutils/u-boot-pine64 ) > B) an OverDrive 1000 (no u-boot build needed) > > I've done amd64->aarch64 cross builds and self hosted ones for/on such. The > OverDrive 1000 builds did not involve devel/aarch64-none-elf-gcc at all as > far as I can remember. > >> and is a prereq for a bunch of sysutils arm ports. > > Yep. > > Are there sysutils/u-boot-* 's that no longer build under gcc 6.4.0? > Other things? > >> At worst we can do something like what's done with the lang ports gcc6, >> gcc7, gcc8. I've CC'd the maintainers so hopefully they can give us some >> input and we can come up with a solution. >> >> As for Makefile issues, this is only an issue for the arm-none-eabi-gcc and >> aarch64-none-elf-gcc ports because they have multiple hyphens. It's mostly a >> cosmetic issue. Each port has its own plist because gcc generates different >> headers depending on the platform so the PLIST TARGETARCH regex doesn't >> really affect all that much. There are some clang flags dependent on >> TARGETARCH but whoever wrote the aarch64-none-elf-gcc port must have known >> it wasn't working in the master because the check is in the bare metal port >> as well. The stripping out of all hyphens causes things like "gcc versio
Re: maintenance of gcc cross ports
On 2019-May-21, at 06:56, James Shuriff wrote: > What do you think of updating the bare metals to 9.1.0? I don’t know anything > outside of U-Boot and the PSCI Monitor (rpi-firmware) that actually depends > on those ports and I've tested them with my custom ports. The powerpc64-gcc > patches aren't needed to build the bare metal ports. Neither port has listed > maintainers. I am willing to maintain them if no one else wants to. I managed > to get U-Boot to build without GCC but it was a tremendous effort and > required a lot of patches. I've submitted some patches to the U-Boot team but > I don't think they're going to accept them. > > Bug report for regular expression issues is here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237982 FYI: QUOTE svn commit: r502188 - head/lang/gcc9-devel . . . Author: gerald Date: Tue May 21 05:52:16 2019 New Revision: 502188 URL: https://svnweb.freebsd.org/changeset/ports/502188 Log: Update to the 20180518 snapshot of GCC 9.1.1. Proactively add a CONFLICTS statement with the lang/gcc9 port that should be landing any day now. That'll avoid a PORTREVISION bump and rebuild at that point. END QUOTE I do not know if you have been in contact with gerald but he normally covers the lang/gcc* ports. You might end up coordinating with him. > - James Shuriff > > -Original Message- > From: John Baldwin > Sent: Monday, May 20, 2019 4:45 PM > To: James Shuriff ; Mark Millard > Cc: ports-list freebsd ; b...@freebsd.org > Subject: Re: maintenance of gcc cross ports > > I do think it probably makes sense to divorce the baremetal GCC ports from > powerpc64-gcc and let powerpc64-gcc just be the basis for FreeBSD-specific > toolchains. > > On 5/19/19 10:48 AM, James Shuriff wrote: >> I have a Raspberry Pi 3 model b. I use the LLVM toolchain to build the >> system but the GNU toolchain is required to build U-Boot. U-Boot uses global >> register variables and LLVM doesn't support this. sysutils/u-boot-pine64 >> does use aarch64-none-elf-gcc, for the same reason. The family is >> allwinner64 and that's set to use aarch64-none-elf-gcc. Here is an article >> explaining the feature U-Boot uses that's not in LLVM (the reason GNU is >> required for building it): >> >> https://gcc.gnu.org/onlinedocs/gcc/Global-Register-Variables.html >> >> Aarch64 is a Tier 2 architecture. The toolchain should have an active >> maintainer (the maintainer is listed as po...@freebsd.org). I've opened a >> bug report for the bugs in the Makefile. We should be using a newer >> toolchain or separate arm-none-eabi and aarch64-none-elf from powerpc64. I >> am guessing the Makefile bugs occurred because the original designer didn't >> intend on powerpc64-gcc being used for targets like arm-none-eabi and >> aarch64-none-elf. The patches you pointed out before don't even have any >> effect on the bare metal ports. The arm and aarch64 bare metal ports are the >> oddballs in the group. The difference being: powerpc64-gcc, aarch64-gcc, >> amd64-gcc, i386-gcc, mips*-gcc, and sparc64-gcc are all intended for, as you >> said Mark, alternate toolchain work with FreeBSD. These are not the official >> toolchains for FreeBSD and I can see why they don't have the same level of >> care as the official toolchain. But the side effect of this is >> arm-none-eabi-gcc and aarch64-none-elf-gcc receive the same level of >> support, though they are *required* to build most FreeBSD systems on those >> platforms. >> >> - James Shuriff >> >> -Original Message- >> From: Mark Millard >> Sent: Sunday, May 19, 2019 11:46 AM >> To: James Shuriff >> Cc: ports-list freebsd ; b...@freebsd.org; >> j...@freebsd.org >> Subject: Re: maintenance of gcc cross ports >> >> >> >> On 2019-May-19, at 07:40, James Shuriff wrote: >> >>> I didn't/don't plan on touching binutils. Binutils is okay. I made new >>> patches as well. What I'm really concerned with bringing up to date is >>> aarch64-none-elf-gcc. >> >>> The GNU toolchain is unfortunately required for building an Aarch64 >>> system >> >> Are you specifically referencing contexts that need to build u-boot? >> (My guess is: yes.) >> >> I've done buildworld buildkernel based on system clang and lld many >> times in the past, though not very recently. (I currently do not have >> access to the environment but will again, eventually.) >> >> For aarch64 I'd mostly recently built for and used: >> >> A) a Pine64+ 2GB (needs: sysutils/u-boot-pine64 ) >> B) an OverDrive 1000 (no u-boot build needed) >> >> I've done amd64->aarch64 cross builds and self hosted ones for/on such. The >> OverDrive 1000 builds did not involve devel/aarch64-none-elf-gcc at all as >> far as I can remember. >> >>> and is a prereq for a bunch of sysutils arm ports. >> >> Yep. >> >> Are there sysutils/u-boot-* 's that no longer build under gcc 6.4.0? >> Other things? >> >>> At worst we can do something like what's done with the lang ports gcc6
Re: maintenance of gcc cross ports
On 5/21/19 6:56 AM, James Shuriff wrote: > What do you think of updating the bare metals to 9.1.0? I don’t know anything > outside of U-Boot and the PSCI Monitor (rpi-firmware) that actually depends > on those ports and I've tested them with my custom ports. The powerpc64-gcc > patches aren't needed to build the bare metal ports. Neither port has listed > maintainers. I am willing to maintain them if no one else wants to. I managed > to get U-Boot to build without GCC but it was a tremendous effort and > required a lot of patches. I've submitted some patches to the U-Boot team but > I don't think they're going to accept them. > > Bug report for regular expression issues is here: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237982 I don't have an opinion on the bare metal ports, the ones I care about are the -gcc ports used as a FreeBSD toolchain. I would ask bapt@ and/or manu@ what they think about having you maintain the bare metal ports. -- John Baldwin ___ 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"
UNAME_r and OSVERSION mismatch - annoying error
Hi, poudriere options -c -j 12rel0 -p local -z desktop audio/sdl_sound throws at me: make: "/usr/local/poudriere/ports/gui/Mk/bsd.port.mk" line 1203: UNAME_r (12.0-RELEASE-p4) and OSVERSION (1102000) do not agree on major version number. What's the easiest way for (temporarily) disabling this error so that I can set the options? Yes, poudriere is compiling with 12.0-RELEASE-p4 jail on a host with 12.0-RELEASE-p4 kernel but with 11.2-RELEASE-p4 userland. I am just in the middle of upgrading the ports and need to recompile one port with different options before I can finish upgrading the userland. Also, is this error expected in that scenario? When I was trying to compile using 12 jail on a host with 11 kernel poudriere was only showing an error that build errors may occur but never refused to at least try to compile. This makefile doesn't even try to set my options. Pretty annoying. I guess I would support merging this patch: https://lists.freebsd.org/pipermail/freebsd-ports/2015-June/099621.html Thanks GrzegorzJ ___ 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: FYI: Unable to build -r501994 ports' devel/qt5-core on clang 8 based powerpc64 system: "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform"
I'm top posting because the problem originally reported seems to be
a later consequence of a much earlier problem. Looking in the logs
showed lots of use of -I%%LOCALBASE%%/lib/gcc8/include/c++ and looking in:
/wrkdirs/usr/ports/devel/qt5-core/work/qtbase-everywhere-src-5.12.2/mkspecs/freebsd-g++/qmake.conf
shows:
EXTRA_INCLUDEPATH += /usr/local/lib/gcc8/include
%%LOCALBASE%%/lib/gcc8/include/c++
That seems to drive from the qmake.conf.bak:
EXTRA_INCLUDEPATH += /usr/local/lib/gcc%%GCC_DEFAULT%%/include
%%LOCALBASE%%/lib/gcc%%GCC_DEFAULT%%/include/c++
So %%GCC_DEFAULT%% managed to be replaced corrctly.
Notably qmake.conf.orig does not have the line at all:
#
# qmake configuration for freebsd-g++
#
MAKEFILE_GENERATOR = UNIX
QMAKE_PLATFORM = freebsd
include(../common/bsd/bsd.conf)
# Addon software goes into /usr/local on FreeBSD, by default we will look there
QMAKE_INCDIR_POST = /usr/local/include
QMAKE_LIBDIR_POST = /usr/local/lib
include(../common/gcc-base-unix.conf)
include(../common/g++-unix.conf)
load(qt_config)
/usr/ports/Mk/Uses/qt-dist.mk has:
post-patch: gcc-post-patch
gcc-post-patch:
${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
${WRKSRC}/mkspecs/common/gcc-base.conf \
${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
${REINPLACE_CMD} 's|%%GCC_DEFAULT%%|${GCC_DEFAULT}|g' \
${WRKSRC}/mkspecs/common/gcc-base.conf \
${WRKSRC}/mkspecs/common/g++-base.conf \
${WRKSRC}/mkspecs/common/bsd/bsd.conf \
${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
and:
post-patch: qtbase-post-patch
qtbase-post-patch:
${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
${WRKSRC}/mkspecs/common/bsd/bsd.conf \
${WRKSRC}/mkspecs/freebsd-clang/qmake.conf
My guess here is that back in gcc-post-patch:
gcc-post-patch:
${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
${WRKSRC}/mkspecs/common/gcc-base.conf \
${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
. . .
it needs -e and a g in order to do more than one substitution:
gcc-post-patch:
${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
${WRKSRC}/mkspecs/common/gcc-base.conf \
${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
. . .
On 2019-May-19, at 07:40, Mark Millard wrote:
> This was in a poudriere bulk build on a head -r347549 based powerpc64
> system with system clang 8 for cc and c++ and base/binutils
> for the likes of ld. But the build of qt5-core uses g++8.
>
> The log shows:
>
> --- .obj/qatomic.o ---
> g++8 -c -O2 -pipe -g -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc8
> -Wl,-rpath=/usr/local/lib/gcc8 -Og -std=c++1z -fvisibility=hidden
> -fvisibility-inlines-hidden -Wall -W -pthread -fPIC -DQT_GLIB
> -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH
> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT
> -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
> -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
> -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -D_LARGEFILE64_SOURCE
> -D_LARGEFILE_SOURCE -I. -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5
> -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty
> -I../3rdparty/double-conversion/include
> -I../3rdparty/double-conversion/include/double-conversion
> -I../3rdparty/forkfd -I../3rdparty/tinycbor/src -I../../include
> -I../../include/QtCore -I../../include/QtCore/5.12.2
> -I../../include/QtCore/5.12.2/QtCore -I.moc -I.tracegen -isystem
> /usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
> -I/usr/local/lib/gcc8/includ
e -I%%LOCALBASE%%/lib/gcc8/include/c++ -isystem /usr/local/include
-I/usr/local/lib/qt5/mkspecs/freebsd-g++ -o .obj/qatomic.o thread/qatomic.cpp
> thread/qatomic.cpp:1624:4: error: #error "Q_ATOMIC_INT64_IS_SUPPORTED must be
> defined on a 64-bit platform"
> # error "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform"
>^
> In file included from ../../include/QtCore/qglobal.h:1,
> from thread/qatomic.h:41,
> from thread/qatomic.cpp:41:
> ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h: In
> instantiation of 'class QBasicAtomicInteger':
> ../../include/QtCore/../../src/corelib/thread/qatomic.h:55:7: required from
> 'class QAtomicInteger'
> thread/qatomic.cpp:1631:1: required from here
> ../../include/QtCore/../../src/corelib/global/qglobal.h:121:63: error: static
> assertion failed: template parameter is an integral of a size not supported
> on this platform
> # define Q_STATIC_ASSERT_X(Condition, Message)
> static_assert(bool(Condition), Message)
> ^~~
> ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h:97:5: note: in
> expansion of macro 'Q_STATIC_ASSERT_X'
> Q_STATIC_ASSERT_X(QAtomicOpsSupport::IsSupp
Re: FYI: Unable to build -r501994 ports' devel/qt5-core on clang 8 based powerpc64 system: "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform"
On 2019-May-21, at 16:20, Mark Millard wrote:
> I'm top posting because the problem originally reported seems to be
> a later consequence of a much earlier problem. Looking in the logs
> showed lots of use of -I%%LOCALBASE%%/lib/gcc8/include/c++ and looking in:
>
> /wrkdirs/usr/ports/devel/qt5-core/work/qtbase-everywhere-src-5.12.2/mkspecs/freebsd-g++/qmake.conf
>
> shows:
>
> EXTRA_INCLUDEPATH += /usr/local/lib/gcc8/include
> %%LOCALBASE%%/lib/gcc8/include/c++
>
>
> That seems to drive from the qmake.conf.bak:
>
> EXTRA_INCLUDEPATH += /usr/local/lib/gcc%%GCC_DEFAULT%%/include
> %%LOCALBASE%%/lib/gcc%%GCC_DEFAULT%%/include/c++
>
> So %%GCC_DEFAULT%% managed to be replaced corrctly.
>
> Notably qmake.conf.orig does not have the line at all:
>
> #
> # qmake configuration for freebsd-g++
> #
>
> MAKEFILE_GENERATOR = UNIX
> QMAKE_PLATFORM = freebsd
>
> include(../common/bsd/bsd.conf)
>
> # Addon software goes into /usr/local on FreeBSD, by default we will look
> there
> QMAKE_INCDIR_POST = /usr/local/include
> QMAKE_LIBDIR_POST = /usr/local/lib
>
> include(../common/gcc-base-unix.conf)
> include(../common/g++-unix.conf)
> load(qt_config)
>
>
>
> /usr/ports/Mk/Uses/qt-dist.mk has:
>
> post-patch: gcc-post-patch
> gcc-post-patch:
>${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
>${WRKSRC}/mkspecs/common/gcc-base.conf \
>${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
>${REINPLACE_CMD} 's|%%GCC_DEFAULT%%|${GCC_DEFAULT}|g' \
>${WRKSRC}/mkspecs/common/gcc-base.conf \
>${WRKSRC}/mkspecs/common/g++-base.conf \
>${WRKSRC}/mkspecs/common/bsd/bsd.conf \
>${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
>
> and:
>
> post-patch: qtbase-post-patch
> qtbase-post-patch:
>${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
>${WRKSRC}/mkspecs/common/bsd/bsd.conf \
>${WRKSRC}/mkspecs/freebsd-clang/qmake.conf
>
>
> My guess here is that back in gcc-post-patch:
>
> gcc-post-patch:
>${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
>${WRKSRC}/mkspecs/common/gcc-base.conf \
>${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
> . . .
>
> it needs -e and a g in order to do more than one substitution:
Actually the -e would be optional and appears to not be
needed in qtbase-post-patch as well --or could be added
to the %%GCC_DEFAULT%% replacement.
The "g" is the important part.
> gcc-post-patch:
>${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
>${WRKSRC}/mkspecs/common/gcc-base.conf \
>${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
> . . .
>
> On 2019-May-19, at 07:40, Mark Millard wrote:
>
>> This was in a poudriere bulk build on a head -r347549 based powerpc64
>> system with system clang 8 for cc and c++ and base/binutils
>> for the likes of ld. But the build of qt5-core uses g++8.
>>
>> The log shows:
>>
>> --- .obj/qatomic.o ---
>> g++8 -c -O2 -pipe -g -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc8
>> -Wl,-rpath=/usr/local/lib/gcc8 -Og -std=c++1z -fvisibility=hidden
>> -fvisibility-inlines-hidden -Wall -W -pthread -fPIC -DQT_GLIB
>> -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH
>> -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB
>> -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
>> -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
>> -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -D_LARGEFILE64_SOURCE
>> -D_LARGEFILE_SOURCE -I. -Iglobal -I../3rdparty/harfbuzz/src
>> -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I../3rdparty
>> -I../3rdparty/double-conversion/include
>> -I../3rdparty/double-conversion/include/double-conversion
>> -I../3rdparty/forkfd -I../3rdparty/tinycbor/src -I../../include
>> -I../../include/QtCore -I../../include/QtCore/5.12.2
>> -I../../include/QtCore/5.12.2/QtCore -I.moc -I.tracegen -isystem
>> /usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include
>> -I/usr/local/lib/gcc8/inclu
de -I%%LOCALBASE%%/lib/gcc8/include/c++ -isystem /usr/local/include
-I/usr/local/lib/qt5/mkspecs/freebsd-g++ -o .obj/qatomic.o thread/qatomic.cpp
>> thread/qatomic.cpp:1624:4: error: #error "Q_ATOMIC_INT64_IS_SUPPORTED must
>> be defined on a 64-bit platform"
>> # error "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform"
>> ^
>> In file included from ../../include/QtCore/qglobal.h:1,
>>from thread/qatomic.h:41,
>>from thread/qatomic.cpp:41:
>> ../../include/QtCore/../../src/corelib/thread/qbasicatomic.h: In
>> instantiation of 'class QBasicAtomicInteger':
>> ../../include/QtCore/../../src/corelib/thread/qatomic.h:55:7: required
>> from 'class QAtomicInteger'
>> thread/qatomic.cpp:1631:1: required from here
>> ../../include/QtCore/../../src/corelib/global/qglobal.h:121:63: error:
>> static assertion failed: template
Re: graphics/php*-gd requires X11 by default
Never mind! I just saw that this was fixed in October for php73-gd. Need to update my PHP version. On Thu, May 16, 2019 at 8:54 PM Greg Kennedy wrote: > I'm raising this again as the last time I tried to check with the port > maintainer, he had not made the change, and wasn't available to do so. > > Can someone change the default config for graphics/php72-gd from X11=on to > X11=off? > > It will save a large number of dependencies on X11, at the cost of not > supporting this (very rarely used) image format. > > On Sat, Sep 15, 2018 at 12:14 PM Greg Kennedy > wrote: > >> I sent an email to the maintainer of these ports (t...@freebsd.org) a few >> days ago, but didn't hear back - so I thought I'd raise the same question >> to the mailing list instead. >> >> --- >> >> Hey there! I was wondering something about the php-gd ports >> (specifically 7.2 but earlier as well). Looking at the config options >> I see this: >> >> X11=on: Enable XPM support >> >> With this option enabled php-gd can read XPixMap images, but in turn >> this pulls in a host of additional X11 dependencies. That's an awful >> lot for (usually) headless servers, especially for an image format >> that is (relatively) unused. I don't mind the option being there but >> because it is defaulted to "on", that means official FreeBSD packages >> are built with this support and all the dependencies. On my system I >> have to manually build this one port just to turn off the option. >> >> Would it be possible to modify the defaults for this port so that >> X11=off by default? Or, why is the default to "on"? (I have a guess, >> that this respects WITHOUT_X11 in /etc/make.conf, but that's useless >> for pre-built binary packages) >> >> -Greg >> > ___ 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: FYI: Unable to build -r501994 ports' devel/qt5-core on clang 8 based powerpc64 system: "Q_ATOMIC_INT64_IS_SUPPORTED must be defined on a 64-bit platform"
[I've tested the proposed Mk/Uses/qt-dist.mk fix.]
On 2019-May-21, at 17:15, Mark Millard wrote:
> On 2019-May-21, at 16:20, Mark Millard wrote:
>
>> I'm top posting because the problem originally reported seems to be
>> a later consequence of a much earlier problem. Looking in the logs
>> showed lots of use of -I%%LOCALBASE%%/lib/gcc8/include/c++ and looking in:
>>
>> /wrkdirs/usr/ports/devel/qt5-core/work/qtbase-everywhere-src-5.12.2/mkspecs/freebsd-g++/qmake.conf
>>
>> shows:
>>
>> EXTRA_INCLUDEPATH += /usr/local/lib/gcc8/include
>> %%LOCALBASE%%/lib/gcc8/include/c++
>>
>>
>> That seems to drive from the qmake.conf.bak:
>>
>> EXTRA_INCLUDEPATH += /usr/local/lib/gcc%%GCC_DEFAULT%%/include
>> %%LOCALBASE%%/lib/gcc%%GCC_DEFAULT%%/include/c++
>>
>> So %%GCC_DEFAULT%% managed to be replaced corrctly.
>>
>> Notably qmake.conf.orig does not have the line at all:
>>
>> #
>> # qmake configuration for freebsd-g++
>> #
>>
>> MAKEFILE_GENERATOR = UNIX
>> QMAKE_PLATFORM = freebsd
>>
>> include(../common/bsd/bsd.conf)
>>
>> # Addon software goes into /usr/local on FreeBSD, by default we will look
>> there
>> QMAKE_INCDIR_POST = /usr/local/include
>> QMAKE_LIBDIR_POST = /usr/local/lib
>>
>> include(../common/gcc-base-unix.conf)
>> include(../common/g++-unix.conf)
>> load(qt_config)
>>
>>
>>
>> /usr/ports/Mk/Uses/qt-dist.mk has:
>>
>> post-patch: gcc-post-patch
>> gcc-post-patch:
>> ${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
>> ${WRKSRC}/mkspecs/common/gcc-base.conf \
>> ${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
>> ${REINPLACE_CMD} 's|%%GCC_DEFAULT%%|${GCC_DEFAULT}|g' \
>> ${WRKSRC}/mkspecs/common/gcc-base.conf \
>> ${WRKSRC}/mkspecs/common/g++-base.conf \
>> ${WRKSRC}/mkspecs/common/bsd/bsd.conf \
>> ${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
>>
>> and:
>>
>> post-patch: qtbase-post-patch
>> qtbase-post-patch:
>> ${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
>> ${WRKSRC}/mkspecs/common/bsd/bsd.conf \
>> ${WRKSRC}/mkspecs/freebsd-clang/qmake.conf
>>
>>
>> My guess here is that back in gcc-post-patch:
>>
>> gcc-post-patch:
>> ${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
>> ${WRKSRC}/mkspecs/common/gcc-base.conf \
>> ${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
>> . . .
>>
>> it needs -e and a g in order to do more than one substitution:
>
> Actually the -e would be optional and appears to not be
> needed in qtbase-post-patch as well --or could be added
> to the %%GCC_DEFAULT%% replacement.
>
> The "g" is the important part.
>
>> gcc-post-patch:
>> ${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
>> ${WRKSRC}/mkspecs/common/gcc-base.conf \
>> ${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
>> . . .
>
Now that the original, overall poudriere bulk is over on the old
PowerMac, I've retried based on:
Index: /usr/ports/Mk/Uses/qt-dist.mk
===
--- /usr/ports/Mk/Uses/qt-dist.mk (revision 501994)
+++ /usr/ports/Mk/Uses/qt-dist.mk (working copy)
@@ -251,7 +251,7 @@
.if ${_QT_VER:M5}
post-patch: gcc-post-patch
gcc-post-patch:
- ${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|' \
+ ${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|g' \
${WRKSRC}/mkspecs/common/gcc-base.conf \
${WRKSRC}/mkspecs/freebsd-g++/qmake.conf
${REINPLACE_CMD} 's|%%GCC_DEFAULT%%|${GCC_DEFAULT}|g' \
@@ -298,7 +298,7 @@
# ports/194088.
post-patch: qtbase-post-patch
qtbase-post-patch:
- ${REINPLACE_CMD} -e 's|%%LOCALBASE%%|${LOCALBASE}|g' \
+ ${REINPLACE_CMD} 's|%%LOCALBASE%%|${LOCALBASE}|g' \
${WRKSRC}/mkspecs/common/bsd/bsd.conf \
${WRKSRC}/mkspecs/freebsd-clang/qmake.conf
(So having the missing g added but not having the optional -e
usage in the other %%LOCALBASE%% related coommand.)
The result was:
[00:02:14] [02] [00:00:00] Building devel/qt5-core | qt5-core-5.12.2_1
[00:39:26] [02] [00:37:12] Finished devel/qt5-core | qt5-core-5.12.2_1: Success
So it looks like I picked out the problem correctly and
Mk/Uses/qt-dist.mk needs an update.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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"
