Thanks. I saw that. It doesn't sound right to me. It sounds like a slight weakening of -fvisibility=hidden. I'll have to experiment more. In particular, will any of GNU ld, Sun ld, Apple ld generate stubs for stuff that was marked hidden but turned out to come from an .so? I am willing to generate versionscripts (GNU)/mapfiles (Sun)/exported symbol list (Apple), since I have information sort of outside the source as to what is where. (It seems GNU ld doesn't allow "eliminate", which is why I'm generating slightly different for GNU vs. Sun.) The key is I want the compiler to think /everything/ is hidden, even though some things are actually imported, and for the linker to fix things up. It is a slight deoptimization for things that end up imported. While it isn't quite my situation, you can imagine if code is all C or extern C, maintaing export lists manually isn't so difficult, not like C++ with its longer lists and mangling. And then no need to sprinkle in annotations in the source/headers as to hidden or not, just use -fvisibility=hidden. As well everything that is exported, I want "protected" (which doesn't currently work in gcc), so telling the compiler "hidden" might be close enough to true? Thanks, - Jay ---------------------------------------- > To: jay.krell@xxxxxxxxxxx > CC: gcc-help@xxxxxxxxxxx > Subject: Re: ideal visibility setting? > From: iant@xxxxxxxxxx > Date: Tue, 18 May 2010 07:43:06 -0700 > > Jay K writes: > >> What I would like is..basically the NT model, but without __declspec(dllimport) >> which is "just" an optimization for functions, but, granted, >> more than that for data. >> I promise not to import/export data. >> I want all symbols, for codegen purposes, to be default assumed to be >> neither exported nor imported. I want to reference functions directly. >> No GOT or PLT references in the "main" code. >> No "interposition". > > See the -fvisibility-ms-compat option. > > Ian
