Re: [kde-freebsd] ports/114734: x11-toolkits/qt4-gui: fails to compile on amd64
devel/qt4-designer fails with the following messages. devel/qt4-linguist also fails because it depends on qt4-designer, but once qt4-designer is fixed, it may build fine. Other ports depending on devel/qt4 seem OK. BTW, most of qt4 ports seem to pass "-g" option to c++ by default. Shouldn't these specify >CONFIGURE_ARGS+= --separate-debug-info=no in the Makefiles to remove it? -- c++ -c -O2 -fno-strict-aliasing -pipe -march=athlon64 -g -fno-exceptions -D_REENTRANT -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -O2 -fno-strict-aliasing -pipe -march=athlon64 -Wall -W -fPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_RASTER_IMAGEENGINE -DQT_HAVE_MMX -DQT_HAVE_SSE -DQT_HAVE_SSE2 -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/usr/local/share/qt4/mkspecs/freebsd-g++ -I. -I../../include/QtCore -I../../include/QtCore -I../../include -I../../include/QtGui -I/usr/local/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-shared -I/usr/local/include -I.uic/release-shared -I/usr/local/include -o .obj/release-shared/qstylesheetstyle.o styles/qstylesheetstyle.cpp ../../include/QtCore/../../src/corelib/arch/qatomic_x86_64.h: In member function `virtual QRect QStyleSheetStyle::subElementRect(QStyle::SubElement, const QStyleOption*, const QWidget*) const': ../../include/QtCore/../../src/corelib/arch/qatomic_x86_64.h:105: error: inconsistent operand constraints in an `asm' ../../include/QtCore/../../src/corelib/arch/qatomic_x86_64.h:105: error: inconsistent operand constraints in an `asm' *** Error code 1 Stop in /usr/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.3.0/src/gui. *** Error code 1 Stop in /usr/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.3.0/tools/designer/src/components/lib. *** Error code 1 Stop in /usr/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.3.0/tools/designer/src/components. *** Error code 1 Stop in /usr/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.3.0/tools/designer/src. *** Error code 1 Stop in /usr/ports/devel/qt4-designer/work/qt-x11-opensource-src-4.3.0/tools/designer. *** Error code 1 Stop in /usr/ports/devel/qt4-designer. ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
Re: [kde-freebsd] ports/114809: x11-toolkits/qt33 - qt-3.3.8_4 install error: don't know how to make qconfig.h
Synopsis: x11-toolkits/qt33 - qt-3.3.8_4 install error: don't know how to make qconfig.h Responsible-Changed-From-To: freebsd-ports-bugs->kde Responsible-Changed-By: edwin Responsible-Changed-When: Sun Jul 22 23:31:17 UTC 2007 Responsible-Changed-Why: Over to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=114809 ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
[kde-freebsd] BEL (primarily for vi).
Apologies for the triple postings, but this is general enough for the -questions list and aimed at the gnome list. It includes a query for the KDE list. I just opened a "konsole", the KDE-hacked xterm, IIRC. I had the BEL set to "system bell" and as with "terminals", vi/vim/and other bell-type things just flashed the screen at me. I do have full-screen flash set up in my Gnome menu settings. Nothing I can do gets the .WAV bell to work under gnome. Long-story-short, just for the heck of it, I tried the next "bell" selection and YES my bell is back when I use vi/nvi/vim. It sounds a bit strange, but at least it is audible. I watch my keyboard and fingers when I type--if I'm not coding--so hearing the bell when I type ESC lets me know absolutely that I'm in command mode. ,My questions: why does this fake (wav) bell work under KDE and not Gnome? The desktop ports are pretty close to identical here (FBSD) as with the Ubuntu fork of Debian. Just FYI.Another question is: why is the natural system spkr disabled in at least the Gnome and KDE managers? What was the rational? In other words, isn't there some default setting that could go into every /boot/loader.conf that would let both the external audio speakers and the dinky system speaker work? The Linux kernel may not have this capability; I don't know. That's why these questions. thanks for any insights, guys. this is enough to make me want to jump back into serious hacking ... well, almost:) gary -- Gary Kline [EMAIL PROTECTED] www.thought.org Public Service Unix ___ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd
