Bugzilla Bug 127020

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 an attachment (id=82720) [details]
wxGTK-2.6.2-r1-filter-flag.patch

Well - don't use -fvisibility-inlines-hidden unless you *really* know what are
you doing. 

Created an attachment (id=82721) [details]
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. ***