I have recently recompiled my system with gcc-4.1 and the following flags (hope it's not to much ricing... if it is, well, thanks to let me know and feel free to mark WONTFIX): % emerge info | grep FLAGS CFLAGS="-march=pentium-m -O2 -pipe -g" CXXFLAGS="-march=pentium-m -O2 -pipe -g -fvisibility-inlines-hidden" LDFLAGS="-Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common" Since then, pgadmin3 (1.4.1 from portage, or 1.4.2 from my overlay) failed to compile (against wxGTK-2.6.2-r1): i686-pc-linux-gnu-g++ -DDATA_DIR=\"/usr/share/pgadmin3/\" -Wall -Wno-non-virtual-dtor -I../src/include -I../src/agent/include -I../src/slony/include -march=pentium-m -O2 -pipe -g -fvisibility-inlines-hidden -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -L/usr/local/pgsql/lib -L/usr/lib -o pgadmin3 pgAdmin3.o base.o appbase.o sysLogger.o pgConnBase.o pgSetBase.o factory.o dlgClasses.o events.o pgConn.o pgSet.o keywords.o pgAggregate.o pgCast.o pgCheck.o pgCollection.o pgColumn.o pgConstraints.o pgConversion.o pgDatabase.o pgDomain.o pgForeignKey.o pgFunction.o pgGroup.o pgIndex.o pgIndexConstraint.o pgLanguage.o pgObject.o pgOperator.o pgOperatorClass.o pgRole.o pgRule.o pgSchema.o pgSequence.o pgServer.o pgTable.o pgTablespace.o pgTrigger.o pgType.o pgUser.o pgView.o pgDatatype.o pgaJob.o pgaStep.o pgaSchedule.o dlgJob.o dlgSchedule.o dlgStep.o xh_sqlbox.o xh_calb.o xh_timespin.o xh_ctlcombo.o ctlSecurityPanel.o ctlComboBox.o ctlTree.o calbox.o timespin.o ctlListView.o ctlSQLBox.o ctlSQLResult.o explainCanvas.o explainShape.o dlgEditGridOptions.o dlgConnect.o dlgHbaConfig.o dlgMainConfig.o dlgSelectConnection.o frmExport.o frmAbout.o frmIndexcheck.o frmMain.o frmOptions.o frmPassword.o frmQuery.o frmHelp.o frmSplash.o frmMaintenance.o frmBackup.o frmRestore.o frmGrantWizard.o frmEditGrid.o frmStatus.o frmUpdate.o frmConfig.o frmHbaConfig.o frmMainConfig.o frmHint.o dlgProperty.o dlgUser.o dlgServer.o dlgGroup.o dlgDatabase.o dlgLanguage.o dlgSchema.o dlgDomain.o dlgTable.o dlgTablespace.o dlgColumn.o dlgIndex.o dlgFunction.o dlgView.o dlgRule.o dlgRole.o dlgOperator.o dlgAggregate.o dlgCast.o dlgConversion.o dlgIndexConstraint.o dlgForeignKey.o dlgSequence.o dlgTrigger.o dlgType.o dlgCheck.o sysSettings.o sysProcess.o misc.o utffile.o pgconfig.o update.o slCluster.o slNode.o slPath.o slListen.o slSet.o slSequence.o slTable.o slSubscription.o dlgRepCluster.o dlgRepNode.o dlgRepListen.o dlgRepPath.o dlgRepSet.o dlgRepSequence.o dlgRepTable.o dlgRepSubscription.o xrcDialogs.o -lssl -lcrypto -lpq -pthread -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -L/usr/X11R6/lib -lwx_gtk2u_xrc-2.6 -lwx_gtk2u_html-2.6 -lwx_gtk2u_adv-2.6 -lwx_gtk2u_core-2.6 -lwx_baseu_xml-2.6 -lwx_baseu_net-2.6 -lwx_baseu-2.6 -pthread -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -L/usr/X11R6/lib -lwx_gtk2u_stc-2.6 -lwx_gtk2u_ogl-2.6 -lwx_baseu-2.6 explainShape.o:(.rodata._ZTV11ExplainLine[vtable for ExplainLine]+0x64): undefined reference to `wxShape::OnLeftDoubleClick(double, double, int, int)' explainShape.o:(.rodata._ZTV11ExplainLine[vtable for ExplainLine]+0xac): undefined reference to `wxShape::OnBeginSize(double, double)' explainShape.o:(.rodata._ZTV11ExplainLine[vtable for ExplainLine]+0xb0): undefined reference to `wxShape::OnEndSize(double, double)' explainShape.o:(.rodata._ZTV11ExplainLine[vtable for ExplainLine]+0xb8): undefined reference to `wxShapeEvtHandler::CopyData(wxShapeEvtHandler&)'explainShape.o:(.rodata._ZTV11ExplainLine[vtable for ExplainLine]+0xec): undefined reference to `wxShape::Recompute()' explainShape.o:(.rodata._ZTV11ExplainLine[vtable for ExplainLine]+0xf0): undefined reference to `wxShape::CalculateSize()' (...and many more like that...) The problem is that with -fvisibility-inlines-hidden, this symbols are dropped from the wxGTK libs. Removing this flag and recompiling wxGTK fixed the issue, so i think it could be candidate for being filtered by flag-o-matic. I will attach an ebuild patch which does that.
Created attachment 82720 [details, diff] wxGTK-2.6.2-r1-filter-flag.patch
Well - don't use -fvisibility-inlines-hidden unless you *really* know what are you doing.
Created attachment 82721 [details, diff] wxGTK-2.6.2-r1-filter-flag.patch oops...
CCing gcc-porting@ in case they have comments about whether -fv-i-h falls in the ricer category, or is a legitimate flag ebuilds should care about. CCing pgsql-bugs@ so that they know about this issue, in case they receive bug reports about it.
(In reply to comment #2) > Well - don't use -fvisibility-inlines-hidden unless you *really* know what are > you doing. > Oops, my previous comment crossed yours. And no, i don't really know what i'm doing :) It's just that i've seen some good feedback about it on f.g.o, and since i had to recompile my system anyway, i've decided to give it a try (no other issue so far btw, but i don't have that much C++ things installed). Thanks for your warning. Btw, is there some kind of list of "supported" C(XX)FLAGS somewhere? I mean, flags that are safe enough for being cared about in ebuilds when they break something. Or is it just -march/-mtune and the -Ox level?
speaking of rice, LDFLAGS=-Wl,--enable-new-dtags is 100% pointless on Gentoo systems ... we patch all of binutils to have this behavior by default
(In reply to comment #6) > speaking of rice, LDFLAGS=-Wl,--enable-new-dtags is 100% pointless on Gentoo > systems ... we patch all of binutils to have this behavior by default > Well, thanks for the info. I feel i will soon go back to my good old settings, since i obviously don't have a clue about this things... /me hides for having temporarily turned into a ricer.
-fvisibility* flags should probably be filtered by _everything_ using C++ right now, as they changes the default visibility scope. This means that if the code is not designed entirely to support them, they break. There is currently no code entirely designed to support them (KDE code is told to be properly designed but no, as it relies on Qt and other C++ libraries that are not and does not push/pop visibility properly), and the effort required to make a software compliant to -fvisibility* changes can be spent instead to make that software hide the symbols that it wants need for sure, rather than telling the compiler to NOT hide symbols that are needed. Added to that, -fvisibility-inlines-hidden is broken wrt PIC handling (see bug #78720). Please note that if the use of -fvisibility* flags does not hinder the build stage, it does not mean that it's safe: KDE 3.4 and 3.5 had crash problems related to dynamic_cast not working because type symbols were hidden and then duplicated again, making comparison impossible, the same will happen to anything relying on RTTI (run time type information).
*** Bug 126906 has been marked as a duplicate of this bug. ***
*** Bug 136883 has been marked as a duplicate of this bug. ***
*** Bug 137005 has been marked as a duplicate of this bug. ***
*** Bug 143297 has been marked as a duplicate of this bug. ***
*** Bug 144550 has been marked as a duplicate of this bug. ***
*** Bug 147774 has been marked as a duplicate of this bug. ***
*** Bug 147216 has been marked as a duplicate of this bug. ***
*** Bug 148894 has been marked as a duplicate of this bug. ***
Reopening to re-assign.
We won't be filtering this flag. If users want to shoot themselves in the foot, they are free to do so and pick up the pieces. :P WONTFIX.
The correct fix would be to use a non broken binutils...
*** Bug 155668 has been marked as a duplicate of this bug. ***
*** Bug 179954 has been marked as a duplicate of this bug. ***
*** Bug 209638 has been marked as a duplicate of this bug. ***
*** Bug 211149 has been marked as a duplicate of this bug. ***
*** Bug 232899 has been marked as a duplicate of this bug. ***
*** Bug 305163 has been marked as a duplicate of this bug. ***
