This forum covers all Gentoo-related software not officially supported by Gentoo. Ebuilds/software posted here might harm the health and stability of your system(s), and are not supported by Gentoo developers. Bugs/errors caused by ebuilds from overlays.gentoo.org are covered by this forum, too.
-Wl,option
Pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas. You can use this syntax to pass an argument to the option. For example, -Wl,-Map,output.map passes -Map output.map to the linker. When using the GNU linker,
you can also get the same effect with -Wl,-Map=output.map.
Last edited by Ormaaj on Thu May 17, 2012 3:15 am, edited 1 time in total.
Ok. Here a conclusion for us more conservative and safety oriented people. When I build my new system with gcc 4.5.1 from scratch (or rather, from stage 3) on a clarkdale CPU, I'd go:
pactoo wrote:Ok. Here a conclusion for us more conservative and safety oriented people. When I build my new system with gcc 4.5.1 from scratch (or rather, from stage 3) on a clarkdale CPU, I'd go:
-mtune=core2 -march=core2 -mfpmath=sse -malign-double -m128bit-long-double -msseregparm -msse4.2 -maes -floop-parallelize-all -floop-interchange -floop-strip-mine -floop-block -fopenmp -fira-loop-pressure -fgraphite-identity -fomit-frame-pointer -ftree-vectorize -O2 -pipe #-flto: not yet, waiting for libtool to catch up
Is that correct? Well, -fomit-frame-pointer is part of O2, but specifying it exclusively, does not matter either.
that might be just for me but:
IMO -fopenmp and -flto still break a lot of (they simply don't compile) - the other should be somewhat fine
does -floop-parallelize-all do anything at all besides indexing parts where it could parallelize ?
You can trigger it by 2 flags -floop-parallelize-all -ftree-parallelize-loops=4. Both of them is needed, the first flag will trigger Graphite pass to mark loops that can be parallel and the second flag will trigger the code generation part.
FWIW, with gcc-4.5.1 I had a problem with -fgraphite-identity and PyQt4, which then prevented me from installing pykde4-4.5.1 and a few other kde-4.5.1 packages, including startkde. Removing -fgraphite-identity just for PyQt4 allowed me to finish up an ~x86 portage kde-4.5.1 update.
Last edited by wrc1944 on Fri Sep 17, 2010 1:53 pm, edited 1 time in total.
wrc1944 wrote:FWIW, with gcc-4.5.1I had a problem with -fgraphite-identity and PyQt4, which then prevented me from installing pykde4-4.5.1 and a few other kde-4.5.1 packages, including startkde. Removing -fgraphite-identity just for PyQt4 allowed me to finish up an ~x86 portage kde-4.5.1 update.
are we able to set cflags per package to work around that?
I forget exactly how, but there was an /etc/portage/bashrc method, and another method way back. A forum search should turn them up. Guess I'll do that now.
mkdir -p /etc/portage/env/app-shells
cd /etc/portage/env/app-shells
echo "CFLAGS=-march=overclock -O666" > bash
Basically you create an basenamed file below /etc/portage/env/<category>/ and put all your C[XX] and LDFLAGS in there
@kernel
gcc itself failed, but I very likely do have broken ram, so until further notice I take back my statement. May have just been coincidence with removing the flag and the larger packages (->gcc) succeed to compile. Some still fail without malign-double and the result of memcheck wasn't exactly pleasant. So once this is fixed, I may retry with double alignment.
With working Ram world builds fine now, even with malign-double. The only thing left not wanting to compile is openoffice. Anyone success with this beast so far?
[Edit] Less ricy and it builds. Will now work my way up. Or not
Linking CXX shared library ../lib/libkdeui.so
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o: In function `KStatusNotifierItem::setContextMenu(KMenu*)':
kstatusnotifieritem.cpp:(.text+0xce3): undefined reference to `DBusMenuExporter::DBusMenuExporter(QString const&, QMenu*, QDBusConnection const&)'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o: In function `KDBusMenuExporter::~KDBusMenuExporter()':
kstatusnotifieritem.cpp:(.text._ZN17KDBusMenuExporterD2Ev[_ZN17KDBusMenuExporterD5Ev]+0xb): undefined reference to `DBusMenuExporter::~DBusMenuExporter()'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o: In function `KDBusMenuExporter::~KDBusMenuExporter()':
kstatusnotifieritem.cpp:(.text._ZN17KDBusMenuExporterD0Ev[_ZN17KDBusMenuExporterD5Ev]+0xf): undefined reference to `DBusMenuExporter::~DBusMenuExporter()'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTV17KDBusMenuExporter[vtable for KDBusMenuExporter]+0x10): undefined reference to `DBusMenuExporter::metaObject() const'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTV17KDBusMenuExporter[vtable for KDBusMenuExporter]+0x18): undefined reference to `DBusMenuExporter::qt_metacast(char const*)'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTV17KDBusMenuExporter[vtable for KDBusMenuExporter]+0x20): undefined reference to `DBusMenuExporter::qt_metacall(QMetaObject::Call, int, void**)'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTI17KDBusMenuExporter[typeinfo for KDBusMenuExporter]+0x10): undefined reference to `typeinfo for DBusMenuExporter'
collect2: ld returned 1 exit status
make[2]: *** [lib/libkdeui.so.5.5.0] Error 1
make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2
make: *** [all] Error 2
benneque wrote:I read the whole thread here and I didn't understand if -graphite-identity is neccessary for graphite to work or not ?!
No clear answers
I have now compiled whole world (incl. KDE 4.5.1 , QT 4.7 , etc.) and just grub2 has those known problems.
My flags are:
wrc1944 wrote:FWIW, with gcc-4.5.1 I had a problem with -fgraphite-identity and PyQt4, which then prevented me from installing pykde4-4.5.1 and a few other kde-4.5.1 packages, including startkde. Removing -fgraphite-identity just for PyQt4 allowed me to finish up an ~x86 portage kde-4.5.1 update.
kdebase-startkde is only a shell script though...
xming wrote:I can't even get kdelibs-4.5.2 compiled with CFLAGS="-O2 -march=native -pipe" on amd64. I get this
Linking CXX shared library ../lib/libkdeui.so
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o: In function `KStatusNotifierItem::setContextMenu(KMenu*)':
kstatusnotifieritem.cpp:(.text+0xce3): undefined reference to `DBusMenuExporter::DBusMenuExporter(QString const&, QMenu*, QDBusConnection const&)'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o: In function `KDBusMenuExporter::~KDBusMenuExporter()':
kstatusnotifieritem.cpp:(.text._ZN17KDBusMenuExporterD2Ev[_ZN17KDBusMenuExporterD5Ev]+0xb): undefined reference to `DBusMenuExporter::~DBusMenuExporter()'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o: In function `KDBusMenuExporter::~KDBusMenuExporter()':
kstatusnotifieritem.cpp:(.text._ZN17KDBusMenuExporterD0Ev[_ZN17KDBusMenuExporterD5Ev]+0xf): undefined reference to `DBusMenuExporter::~DBusMenuExporter()'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTV17KDBusMenuExporter[vtable for KDBusMenuExporter]+0x10): undefined reference to `DBusMenuExporter::metaObject() const'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTV17KDBusMenuExporter[vtable for KDBusMenuExporter]+0x18): undefined reference to `DBusMenuExporter::qt_metacast(char const*)'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTV17KDBusMenuExporter[vtable for KDBusMenuExporter]+0x20): undefined reference to `DBusMenuExporter::qt_metacall(QMetaObject::Call, int, void**)'
CMakeFiles/kdeui.dir/notifications/kstatusnotifieritem.o:(.data.rel.ro._ZTI17KDBusMenuExporter[typeinfo for KDBusMenuExporter]+0x10): undefined reference to `typeinfo for DBusMenuExporter'
collect2: ld returned 1 exit status
make[2]: *** [lib/libkdeui.so.5.5.0] Error 1
make[1]: *** [kdeui/CMakeFiles/kdeui.dir/all] Error 2
make: *** [all] Error 2
this is due to either too agressive link optimization or (more probably) incompatible versions of dbus, qt-dbus and kdelibs (that error messages normally occurs when you forget to moc a Q_OBJECT marked QObject instance).
pjp wrote:
shickapooka800 wrote:there are plenty of ubuntards in coffee shops around the globe these days.
Yes, but they're only smart enough to recognize they want to be popular, yet too stupid to recognize that it isn't a Mac.
I just switched my 2 machines to GCC-4.5. Everything seems fine, except the -O3 CFLAGS that doesn't work in i686 (corrupted stack frames in some cases : [bug=270120]See Bug 270120, present in 4.4 and 4.5[/bug])
When should we expect a release for 4.5.2 version ?
From Tentative Timeline - http://gcc.gnu.org/develop.html#timeline - it seems to be a cycle of about 3 months between each release, but there is no official report, nothing conclusive.
Sorry for my English. I'm still learning this language.
Out of 297 packages, I ran into problems with:
sys-apps/diffutils-2.8.7-r2 (hang fixed with patch from http://bugs.gentoo.org/show_bug.cgi?id=340923 )
sys-apps/net-tools-1.60_p20090728014017-r1 (fixed by unmasking sys-apps/net-tools-1.60_p20100815160931 )
x11-libs/cairo-1.8.10 (ICE fixed by filtering graphite CFLAGS http://bugs.gentoo.org/show_bug.cgi?id=346445 )
I'll probably rebuild world later this week.
Ryzen 3700X, Asus Prime X570-Pro, 64 GB DDR4 3200, GeForce GTX 1660 Super
openrc-0.17, ~vanilla-sources, ~nvidia-drivers, ~gcc
is grub-1.98 now working with gcc 4.5.x ?
I haven't rebuild my whole system with the new patched 4.5.1 release, but instead tried to only rebuild grub-1.98 and I had again the boot error message (wrong pointer or sth...) Would a complete rebuild help?
(grub-9999 still works fine)