I always have to uninstall the port, then it will compile
On Thu, Feb 4, 2021 at 2:10 AM Alex V. Petrov wrote:
>
> log:
> /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
> reference to `re2::RE2::FullMatchN(re2::StringPiece const&, re2::RE2
> const&am
## Alex V. Petrov (alexvpet...@gmail.com):
> /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
> reference to `re2::RE2::FullMatchN(re2::StringPiece const&, re2::RE2
> const&, re2::RE2::Arg const* const*, int)'
> /usr/local/bin/ld: /usr/local/lib/q
log:
/usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
reference to `re2::RE2::FullMatchN(re2::StringPiece const&, re2::RE2
const&, re2::RE2::Arg const* const*, int)'
/usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
reference to `
Connection error after last update, If present even one torrent:
Duplicate object member: "status".
--
-
Alex.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "free
Confirmed. Patch worked for me.
Thank you!
28.11.2020 01:09, Beñat Gonzalez Etxepare пишет:
> Hi,
>
> I have submitted a patch with the fix:
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251426
>
>
> Best regards.
--
-
Alex.
___
freebsd-po
Sorry, but no!
27.11.2020 13:50, Beñat Gonzalez Etxepare пишет:
> (CC me, I am not subscribed)
>
>> /usr/ports/x11-fm/doublecmd/work-qt5/doublecmd-0.9.9/components/multithreadprocs/mtpcpu.pas(80,23)
>> Error: (4025) Incompatible type for arg no. 1: Got "PChar", expec
Info: (lazarus) Execute Title="Compile package MultiThreadProcsLaz 1.2.1"
Info: (lazarus) Working
Directory="/usr/ports/x11-fm/doublecmd/work-qt5/doublecmd-0.9.9/components/multithreadprocs/"
Info: (lazarus) Executable="/usr/local/bin/fpc"
Info: (lazarus) Param[0
] Error code 1
make[1]: stopped in
/wrkdirs/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.15.0/src/gui
--- .obj/pixman-arm-neon-asm.o ---
cc: error: unable to execute command: Executable "as" doesn't exist!
cc: error: assembler command failed with exit code 1 (use -v
On Wed, 8 Jul 2020 15:44:21 +0200, Christoph Moench-Tegeder stated:
>## Carmel NY (carmel...@outlook.com):
>
>> The entire build log, what there is of it, is available here:
>> https://seibercom.net/logs/qt5-network_build.log
>
>And there's your problem:
>:
## Carmel NY (carmel...@outlook.com):
> The entire build log, what there is of it, is available here:
> https://seibercom.net/logs/qt5-network_build.log
And there's your problem:
: /usr/local/etc/poudriere.d/make.conf
:
: LICENSES_ACCEPTED+= PDFlib
: DEFAULT_VERSIONS
updated ports tree, when I attempt to run
>> >> poudriere to update the installed ports, I am greeted with this
>> >> warning:
>> >>
>> >> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is
>> >> marked as broken: Qt5
I am greeted with this warning:
> >>
> >> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked
> >> as broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x
> >> or add DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf
> &
>On Wed, 8 Jul 2020 at 13:10, Carmel NY wrote:
>>
>> FreeBSD 11.4-RELEASE
>>
>> With a freshly updated ports tree, when I attempt to run poudriere to
>> update the installed ports, I am greeted with this warning:
>>
>> [00:00:21] Ignoring net/qt5-
led ports, I am greeted with this warning:
>
> [00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked as
> broken: Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x or add
> DEFAULT_VERSIONS+=ssl=[openssl|libressl*] to /etc/make.conf
>
> Subsequently, 339 ports
FreeBSD 11.4-RELEASE
With a freshly updated ports tree, when I attempt to run poudriere to
update the installed ports, I am greeted with this warning:
[00:00:21] Ignoring net/qt5-network | qt5-network-5.15.0: is marked as broken:
Qt5 requires Openssl 1.1.1, upgrade to FreeBSD 12.x/13.x or add
On 2020-06-18 09:58, Per olof Ljungmark wrote:
Updated ports and 12.1-STABLE r362185
Failures like this, anyone here having the same problem or am I alone?
Asnwering myself: Delete the ports first, then build. Forgot this.
Per
___
freebsd-ports@fre
Updated ports and 12.1-STABLE r362185
Failures like this, anyone here having the same problem or am I alone?
Determining if the __GLIBC__ exist failed with the following output:
Change Dir:
/usr/ports/x11-toolkits/kf5-kdesignerplugin/work/.build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/l
Moin moin
Qt5 dropped support for OpenSSL 1.0 with Qt5-5.15.
As FreeBSD 11 only has OpenSSL 1.0 in base, that means
that there won't be any binary packages for net/qt5-network
and all ports depending on it once Qt5-5.15 lands in the
ports tree.
If you require qt5-network, you have two pos
[Ports was at -r528828 so this did not check
-r531601 update to 5.14.2 of Qt5.]
This is based on worlds built via WITHOUT_BINUTILS= .
I was checking to see how things are for "[o]ne of the goals of
this process [ExternalGCC] is to deprecate and remove the old
GCC 4.2.1 and binutils 2.17.
On Thu, Apr 16, 2020 at 05:08:59PM +0200, Adriaan de Groot wrote:
> On Thursday, 16 April 2020 00:05:02 CEST The Doctor wrote:
> > On Wed, Apr 15, 2020 at 09:20:17PM +0200, Adriaan de Groot wrote:
> > > Qt ports are annoying like that; it's an incompatibility between pre-5.14
> > > and (current) 5.
On 2020-04-16 17:08, Adriaan de Groot wrote:
On Thursday, 16 April 2020 00:05:02 CEST The Doctor wrote:
All right, just that I use portmaster. How can I use poudriere for
this?
https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/testing-poudriere.html
That's from the perspec
On Thursday, 16 April 2020 00:05:02 CEST The Doctor wrote:
> On Wed, Apr 15, 2020 at 09:20:17PM +0200, Adriaan de Groot wrote:
> > Qt ports are annoying like that; it's an incompatibility between pre-5.14
> > and (current) 5.14 where it picks up the wrong CMake support bits.
> > Uninstall Qt < 5.14
On Wed, Apr 15, 2020 at 09:20:17PM +0200, Adriaan de Groot wrote:
> Qt ports are annoying like that; it's an incompatibility between pre-5.14 and
> (current) 5.14 where it picks up the wrong CMake support bits. Uninstall Qt <
> 5.14, then build Qt 5.14. Or use poudriere, which builds in a clean
Qt ports are annoying like that; it's an incompatibility between pre-5.14 and
(current) 5.14 where it picks up the wrong CMake support bits. Uninstall Qt <
5.14, then build Qt 5.14. Or use poudriere, which builds in a clean
environment.
[ade]
signature.asc
Description: This is a digitally sign
call first):
/usr/local/lib/cmake/Qt5Gui/Qt5GuiConfig.cmake:201 (include)
/usr/local/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:100
(find_package)
/usr/local/lib/cmake/Qt5/Qt5Config.cmake:28 (find_package)
CMakeLists.txt:25 (find_package)
CMake Error
## Dan McGrath (danmcgrath...@gmail.com):
> I swear, you find that squirrel you phone me asap! I have the warthogs
> circling looking for him for at least a week now!
https://cybersquirrel1.com/
Regards,
Christoph
--
Spare Space
___
freebsd-ports@fre
Am 05.04.20 um 02:50 schrieb John Kennedy:> The thing that drove me
away from portmaster to synth and eventually to
> poudriere is incompatible dependencies. I was running into those with just
> X11 dependencies (~600 packages in my full port rebuild, so not sure how you
> got lucky over that pe
On Sat, Apr 4, 2020 at 7:43 PM Robert Huff wrote:
> I understand there are folks for whom poudriere or synth are The
> Right Tool(tm). But I am one of a number of folks for whom it is like
> carpet-bombing the neighborhood to get rid of one miscreant squirrel.
>
I swear, you find that s
On Sun, 5 Apr 2020 18:08:27 +0700
"Alex V. Petrov" wrote:
> 04.04.2020 21:10, ajtiM via freebsd-ports пишет:
> > Hi!
> >
> > Today update for qt5-webengine cannot compile:
> >
> > /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so
04.04.2020 21:10, ajtiM via freebsd-ports пишет:
> Hi!
>
> Today update for qt5-webengine cannot compile:
>
> /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
> reference to `re2::RE2::Arg::parse_ulong(char const*, unsigned long,
> void*)' c++: er
On Sat, Apr 04, 2020 at 07:41:54PM -0400, Robert Huff wrote:
> Jonathan Chen writes:
>
>> Frankly speaking, if you're compiling your own ports, you
>> have to use either synth or poudriere; anything else will cost you
>> time hunting down broken dependencies.
>
> Speaking as someone w
Jonathan Chen writes:
>Frankly speaking, if you're compiling your own ports, you
> have to use either synth or poudriere; anything else will cost you
> time hunting down broken dependencies.
Speaking as someone who's been compiling from ports for at least
a decade, and
On Sun, 5 Apr 2020 at 06:46, ajtiM via freebsd-ports
wrote:
[...]
> I did use Synth but all the time compile so many ports and I stop and
> switched back to portmaster. But if I hav problem than I have a problem
> something related to KDE. I am using Openbox. I deleted re2 and all
> ports related
freebsd.org):
> > >
> > > > Today update for qt5-webengine cannot compile:
> > > >
> > > > /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so:
> > > > undefined reference to `re2::RE2::Arg::parse_ulong(char const*,
> > &
On Sat, 4 Apr 2020 11:15:53 -0400
ajtiM via freebsd-ports wrote:
> On Sat, 4 Apr 2020 16:21:03 +0200
> Christoph Moench-Tegeder wrote:
>
> > ## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
> >
> > > Today update for qt5-webengine cannot compile:
> &
On Sat, 4 Apr 2020 16:21:03 +0200
Christoph Moench-Tegeder wrote:
> ## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
>
> > Today update for qt5-webengine cannot compile:
> >
> > /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so:
> > undefin
## ajtiM via freebsd-ports (freebsd-ports@freebsd.org):
> Today update for qt5-webengine cannot compile:
>
> /usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
> reference to `re2::RE2::Arg::parse_ulong(char const*, unsigned long,
> void*)' c++: error: l
Hi!
Today update for qt5-webengine cannot compile:
/usr/local/bin/ld: /usr/local/lib/qt5/libQt5WebEngineCore.so: undefined
reference to `re2::RE2::Arg::parse_ulong(char const*, unsigned long,
void*)' c++: error: linker command failed with exit code 1 (use -v to
see invocation) *** [../../li
Hi!
(3104) Compiling ./platform/uuniqueinstance.pas
(3104) Compiling ./platform/unix/upipeserver.pas
(3104) Compiling ./platform/unix/upollthread.pas
/usr/ports/x11-fm/doublecmd/work-qt5/doublecmd-0.9.8/src/./platform/unix/upollthread.pas(38,21)
Hint: (5024) Parameter "Sender"
or is it FreeBSD specific problem?
I think it is a bit too early to tell. I think it is not really
FreeBSD-specific
but there might be some quirks.
I am rebuilding qt5-webkit now with debug symbols using your phantomfs
port (thanks!) and I'll poke around a bit with debugger.
Just the smal
is a bit too early to tell. I think it is not really
FreeBSD-specific
but there might be some quirks.
I am rebuilding qt5-webkit now with debug symbols using your phantomfs
port (thanks!) and I'll poke around a bit with debugger.
Just the small update.
phantomjs with modified versio
not really
FreeBSD-specific
but there might be some quirks.
I am rebuilding qt5-webkit now with debug symbols using your phantomfs
port (thanks!) and I'll poke around a bit with debugger.
Just the small update.
phantomjs with modified version of qt5-webkit does not render any text /
fonts on
be some quirks.
I am rebuilding qt5-webkit now with debug symbols using your phantomfs
port (thanks!) and I'll poke around a bit with debugger.
Marcin
smime.p7s
Description: S/MIME Cryptographic Signature
my late reply. Rebuilding of qt5-webkit is very strange.
The build crashes with out of memory 3 times but finally I have
qt5-webkit rebuilt with commented out line you suggested and it works now!
The example from my first attempt works:
(root@testjail) ~/# phantomjs /tmp/phantom.2.js
[blocked
anything else.
OK, it is getting closer.
The crash comes from this call:
https://github.com/qtwebkit/qtwebkit/blob/qtwebkit-5.212.0-alpha3/Source/WebCore/css/CSSParser.cpp#L6907
Can you commet comment this line, recompile qtwebkit and see what happens?
I commented out the line number 690
Am 2020-02-24 um 22:52 schrieb Miroslav Lachman:
Michael Osipov wrote on 2020/02/24 21:40:
Am 2020-02-24 um 20:56 schrieb Miroslav Lachman:
[..]
I tried it on simpler website on HTTP without external fonts etc. but
it is still crashing
Example JS code and truss output is on hastebin
https:
Michael Osipov wrote on 2020/02/24 21:40:
Am 2020-02-24 um 20:56 schrieb Miroslav Lachman:
[..]
I tried it on simpler website on HTTP without external fonts etc. but
it is still crashing
Example JS code and truss output is on hastebin
https://hastebin.com/sizefupiki.pl
No fopen found ther
Am 2020-02-24 um 20:56 schrieb Miroslav Lachman:
Michael Osipov wrote on 2020/02/24 20:35:
Am 2020-02-24 um 19:10 schrieb Miroslav Lachman:
Looking at your sample code and the website, there are several issues:
* The resource employs mixed site content HTTPS loads HTTP. Firefox
blocks this
Michael Osipov wrote on 2020/02/24 20:35:
Am 2020-02-24 um 19:10 schrieb Miroslav Lachman:
Looking at your sample code and the website, there are several issues:
* The resource employs mixed site content HTTPS loads HTTP. Firefox
blocks this, I guess WebKit blocks it too.
* Result: Droid S
Am 2020-02-24 um 19:10 schrieb Miroslav Lachman:
Marcin Cieslak wrote on 2020/02/24 18:51:
On Mon, 24 Feb 2020, Marcin Cieslak wrote:
On Mon, 24 Feb 2020, Miroslav Lachman wrote:
frame #13: 0x0008039aa3ed
libQt5WebKit.so.5`WebCore::CSSParser::parseSheet(this=0x7fffa490,
sheet
On Mon, 24 Feb 2020, Miroslav Lachman wrote:
Marcin Cieslak wrote on 2020/02/24 18:51:
On Mon, 24 Feb 2020, Marcin Cieslak wrote:
On Mon, 24 Feb 2020, Miroslav Lachman wrote:
frame #13: 0x0008039aa3ed
libQt5WebKit.so.5`WebCore::CSSParser::parseSheet(this=0x7fffa490,
sheet=0x
Marcin Cieslak wrote on 2020/02/24 18:51:
On Mon, 24 Feb 2020, Marcin Cieslak wrote:
On Mon, 24 Feb 2020, Miroslav Lachman wrote:
frame #13: 0x0008039aa3ed
libQt5WebKit.so.5`WebCore::CSSParser::parseSheet(this=0x7fffa490,
sheet=0x0008155f5e40, string=0x7fffb888,
t
On Mon, 24 Feb 2020, Marcin Cieslak wrote:
On Mon, 24 Feb 2020, Miroslav Lachman wrote:
frame #13: 0x0008039aa3ed
libQt5WebKit.so.5`WebCore::CSSParser::parseSheet(this=0x7fffa490,
sheet=0x0008155f5e40, string=0x7fffb888,
textPosition=0x7fffb650,
ruleSource
On Mon, 24 Feb 2020, Miroslav Lachman wrote:
"phantomjs" can run simple "Hello world" example
https://github.com/ariya/phantomjs/blob/master/examples/hello.js
But when I try to run some real work (fetching web page) it segfaulted.
Looks like Qt5Webkit has a problem reading CSS for the web pag
Michael Osipov wrote on 2020/02/24 16:47:
Am 2020-02-24 um 16:35 schrieb Miroslav Lachman:
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/local/lib/qt5/libQt5WebKitWidgets.so.5...done.
Loaded symbols for /usr/local/lib/qt5/libQt5WebKitWidgets.so.5
Reading symbols from /usr
On Mon, 24 Feb 2020, Michael Osipov wrote:
(root@testjail) ~/# gdb /usr/local/bin/phantomjs
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
Can you try gdb from ports?
/usr/local/bin/gdb831 works much better with a modern C++ applications.
Marcin
smime.p7s
Description:
md64-marcel-freebsd"...(no debugging
symbols found)...
Core was generated by `/usr/local/bin/phantomjs /tmp/phantom.2.js'.
Program terminated with signal 5, Trace/breakpoint trap.
Reading symbols from /usr/lib/libdl.so.1...Reading symbols from
/usr/lib/debug//usr/lib/libdl.so.1.debug...don
tom.2.js'.
Program terminated with signal 5, Trace/breakpoint trap.
Reading symbols from /usr/lib/libdl.so.1...Reading symbols from
/usr/lib/debug//usr/lib/libdl.so.1.debug...done.
done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/local/lib/qt5/libQt5WebKitWidgets.so.5...d
Am 2020-02-24 um 15:50 schrieb Miroslav Lachman:
Miroslav Lachman wrote on 2020/02/24 12:48:
Short story:
I am trying to build qt5-webkit with WITH_DEBUG=yes in make.conf on
our E3 Xeon machine with FreeBSD 11.3, poudriere-devel, 16GB of RAM
and 10GB of swap.
The build always hangs, machine
Miroslav Lachman wrote on 2020/02/24 12:48:
Short story:
I am trying to build qt5-webkit with WITH_DEBUG=yes in make.conf on our
E3 Xeon machine with FreeBSD 11.3, poudriere-devel, 16GB of RAM and 10GB
of swap.
The build always hangs, machine is unresponsive on SSH / HTTP, only ping
is
Short story:
I am trying to build qt5-webkit with WITH_DEBUG=yes in make.conf on our
E3 Xeon machine with FreeBSD 11.3, poudriere-devel, 16GB of RAM and 10GB
of swap.
The build always hangs, machine is unresponsive on SSH / HTTP, only ping
is responding. I track it down to build eats all
Hello,
I use security/pinentry-qt5 in KDE5 on FreeBSD CURRENT (all from SVN
HEAD, compiled by my own, ports with poudriere on February, 11).
security/pinentry-qt5 is used to unlock my OpenPGP card. In the past the
pinentry-qt5 pop-up window have had automatically the focus, now the
focus stays
imple example test):
"/usr/local/bin/as" "-mfpu=vfp" "-meabi=5" "-o" "a.o" "/tmp/a-14ae2e.s"
and that in turn presumes that devel/binutils has provided
/usr/local/bin/as .
That in turn means that, for ports-mgmt/poudriere-devel to
Adriaan de Groot writes:
> Basically, Qt is using internal headers that it shouldn't .. but
> that means we need to make Qt depend on evdev-proto. There is a fix
> in the works.
_Please_ announce this in UPDATING.
Respectfully,
On Thursday, 10 October 2019 14:05:56 CEST freebsd-ports-requ...@freebsd.org
wrote:
> > I've run into the same error just yesterday. As a workaround, deinstall
> > the devel/evdev-proto port (it's not the libmtdev port which is the
> > problem) and it will use the base-system evdev includes.
> >
he definitions /usr/include/dev/evdev/input.h from base.
>> This is in the middle of a portmaster qt5 upgrade, trying to
>> reinstall qt5-gui-5.12.2_1. I didn't see anything in UPDATING
>> that seemed relevant. My ports tree is at 514153. -- George
>
> I've run i
Quoting George Mitchell (from Wed, 9 Oct 2019
10:12:39 -0400):
Apparently the definitions of various structures found in
/usr/local/include/mtdev.h from libmtdev-1.1.5_2 conflict with
the definitions /usr/include/dev/evdev/input.h from base.
This is in the middle of a portmaster qt5 upgrade
Apparently the definitions of various structures found in
/usr/local/include/mtdev.h from libmtdev-1.1.5_2 conflict with
the definitions /usr/include/dev/evdev/input.h from base.
This is in the middle of a portmaster qt5 upgrade, trying to
reinstall qt5-gui-5.12.2_1. I didn't see anythi
see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240964
___
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"
../../../include/QtDeviceDiscoverySupport/5.13.0/QtDeviceDiscoverySupport
-isystem /usr/loca
l/include/qt5/QtCore/5.13.0 -isystem
/usr/local/include/qt5/QtCore/5.13.0/QtCore -isystem
/usr/local/include/qt5 -isystem /usr/local/include/qt5/QtCore -I.moc
-isystem /usr/local/include/libdrm -isystem /usr
gt; Getting a compilation error when build ports/textproc/qt5-xmlpatterns
> > That suggests that you still have older Qt bits installed, while building
> > newer Qt bits. You will want to follow the common instructions we (kde@)
> > give if you're not building with poudr
Maybe, this helps:
https://forums.freebsd.org/threads/qt5-xmlpatterns-failing-to-compile.69450/
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-
On 29/06/2019 05:29, Adriaan de Groot wrote:
On Friday, 28 June 2019 14:00:01 CEST freebsd-ports-requ...@freebsd.org wrote:
[FreeBSD 11.3-PRERELEASE #1 r349440 amd64 / ports at r505184]
Getting a compilation error when build ports/textproc/qt5-xmlpatterns
I'm doing a 'portmaster -a&
[FreeBSD 11.3-PRERELEASE #1 r349440 amd64 / ports at r505184]
Getting a compilation error when build ports/textproc/qt5-xmlpatterns
I'm doing a 'portmaster -a' but a
'cd /usr/ports/textproc/qt5-xmlpatterns ; make clean all' does the same.
Any clues as to why thi
they assume _either_ llvm _or_ gcc in base. This would fix your specific
>> problem but not the general problem of someone installing both and then
>> switching back and forth for testing.
>
> Plus qt5 is outside the range of gcc 4.2.1 to cover, so for it
> a usable "
e "real" fix is.
> I consider what we've done in some places to not be the "real" fix because
> they assume _either_ llvm _or_ gcc in base. This would fix your specific
> problem but not the general problem of someone installing both and then
> switching back a
[I adjusted the Subject line to give more context.]
[/usr/local/lib/qt5/bin/qlalr and /usr/local/lib/qt5/libQt5Core.so.5
overall use each of the following (somewhat indirectly) in my
system-clang-8-based powerpc64 context:
/usr/local/lib/gcc8/libstdc++.so.6
/usr/lib/libc++.so.1
/lib/libcxxrt.so.1
:21, Mark Millard wrote:
>>>
>>>> The poudriere bulk run that tried to build x11-toolkits/qt5-declarative
>>>> got:
>>>>
>>>> --- qqmljsgrammar.cpp ---
>>>> /usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g
>>
gt;>
>> [I should have listed uname -apKU output and such.]
>>
>> On 2019-May-23, at 13:21, Mark Millard wrote:
>>
>>> The poudriere bulk run that tried to build x11-toolkits/qt5-declarative
>>> got:
>>>
>>> --- qqmljsgrammar.cpp ---
[It looks like code generation missed a level of indirection
to me.]
> On 2019-May-23, at 13:46, Mark Millard wrote:
>
> [I should have listed uname -apKU output and such.]
>
> On 2019-May-23, at 13:21, Mark Millard wrote:
>
>> The poudriere bulk run that tried t
[I should have listed uname -apKU output and such.]
On 2019-May-23, at 13:21, Mark Millard wrote:
> The poudriere bulk run that tried to build x11-toolkits/qt5-declarative
> got:
>
> --- qqmljsgrammar.cpp ---
> /usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g
>
The poudriere bulk run that tried to build x11-toolkits/qt5-declarative
got:
--- qqmljsgrammar.cpp ---
/usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g
Segmentation fault (core dumped)
*** [qqmljsgrammar.cpp] Error code 139
make[3]: stopped in
/wrkdirs/usr/ports/x11-toolkits/qt5
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
dirs/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_IN
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/free
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
On Thu, May 09, 2019 at 05:20:54PM +0100, tech-lists wrote:
Seems to fail starting from here:
[00:02:43] [8124/14059] CXX host/obj/third_party/boringssl/boringssl/bio_ssl.o
[00:02:43] [8125/14059] LINK ./mksnapshot
[00:02:43] FAILED: mksnapshot
Seems this was down to bad files in the ccache ca
Seems to fail starting from here:
[00:02:43] [8124/14059] CXX host/obj/third_party/boringssl/boringssl/bio_ssl.o
[00:02:43] [8125/14059] LINK ./mksnapshot
[00:02:43] FAILED: mksnapshot
--
J.
signature.asc
Description: PGP signature
r_sources/preloaded_state_generator.o
[8100/14061] CXX
host/obj/net/tools/transport_security_state_generator/transport_security_state_generator_sources/input_file_parsers.o
[8101/14061] ACTION
//chrome/app:generated_resources_grit(/wrkdirs/usr/ports/www/qt5-webengine/work/.build/src/toolchain:target)
ninja: build stop
sort of looks like it happened during a configuration step.
>
> Okay, can you create a PR and attach one .sh and .cpp file which belong
> together (they should have the same random suffix of hex digits)? It is
> likely that we can then reproduce it independently of your particular
it was successful. But this morning's daily
>>> status report revealed that clang had crashed on a signal 11 once
>>> while compiling each qt5 package. (For once, it was useful to have
>>> the "such-and-such installed" messages in the system log.)
aled that clang had crashed on a signal 11 once
>> while compiling each qt5 package. (For once, it was useful to have
>> the "such-and-such installed" messages in the system log.) So I just
>> tried recompiling qt5-qmake just now under "script". Sure enough,
&g
On 10 Apr 2019, at 19:37, George Mitchell wrote:
>
> Yesterday I went through a round of updating and compiling ports. By
> all outward appearances it was successful. But this morning's daily
> status report revealed that clang had crashed on a signal 11 once
> while compil
Yesterday I went through a round of updating and compiling ports. By
all outward appearances it was successful. But this morning's daily
status report revealed that clang had crashed on a signal 11 once
while compiling each qt5 package. (For once, it was useful to have
the "suc
On 3/30/19 10:49 PM, Davide Beatrici wrote:
> Greetings,
>
> I would like to inform you
> about https://bugreports.qt.io/browse/QTBUG-74844.
>
> A patch is attached to the bug report.
>
> Best regards,
> Davide
Thanks for the heads-up. Please note that you are a lot more likely to
get your patc
>>>>> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
>>>>>> CONFIGURE_ARGS+=-no-sse2
>>>>>> .endif
>>>>>
>>>>> Hmmm. Oh well. I set CPUTYPE=core2 in /etc/make.conf.
>>>>&g
t;>> On Sun, Feb 10, 2019 at 03:14:15PM -0800, Mark Millard wrote:
>>>>>
>>>>> /usr/ports/Mk/Uses/qt-dist.mk has:
>>>>>
>>>>> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
>>>>> CONFIGURE_ARGS+=
Millard wrote:
>>>>
>>>> /usr/ports/Mk/Uses/qt-dist.mk has:
>>>>
>>>> .if ${ARCH} == i386 && empty(MACHINE_CPU:Msse2)
>>>> CONFIGURE_ARGS+=-no-sse2
>>>> .endif
>>>
>>> Hmmm. Oh
of it.
>
> This is something that's going to need .. well, preferably Pjotr Kubaj who
> has
> access to suitable machines .. someone to chase the build and figure out what
> is #defined exactly and which (qmake) configurations are in use.
>
Looking, I can confirm QT_NO_B
On Monday, 11 March 2019 13:01:43 CET freebsd-ports-requ...@freebsd.org wrote:
> ../qbearerengine_impl.h:48:1: error: expected class-name before '{' token
I *imagine* (since I don't have anything that can try to reproduce this build
sensibly) that you're hitting a case where QT_NO_BEARERMANAGEMEN
1 - 100 of 248 matches
Mail list logo
