[sane-devel] [RFC] On libsane symbols visibility

Julien BLACHE writes: > Olaf Meeuwissen wrote: > > Hi, > >> Seconded, but sane-backends uses libtool so I think you can achieve >> what you are trying to quite easily without modifying sources using >> one of the following options: >> >> -export-symbols SYMFILE >> try to ex

[sane-devel] [RFC] On libsane symbols visibility

> Message-ID: <87sla68iw4@sonic.technologeek.org> > > > Haven't tried this myself so YMMV. > > That would be an excellent solution, provided it works with our > modified version of libtool (for those unaware of it, sane-backends > uses a slightly modified libtool version, so be careful if you

[sane-devel] [RFC] On libsane symbols visibility

Olaf Meeuwissen wrote: Hi, > Seconded, but sane-backends uses libtool so I think you can achieve > what you are trying to quite easily without modifying sources using > one of the following options: > > -export-symbols SYMFILE > try to export only the symbols listed in SYMF

[sane-devel] [RFC] On libsane symbols visibility

Julien BLACHE writes: > "Ilia Sotnikov" wrote: > >> My suggestion is to mark the functions which are part of SANE API as >> exportable (__attribute__ ((visibility("default"))) symbol attribute >> and its companion, -fvisibility=hidden). It will give us the necessary >> result - only explicitly m

[sane-devel] [RFC] On libsane symbols visibility

Francesco Pietra wrote: Hi, > I wish I can find the way to remove my address from > the list without giving the pass word > Thanks for help I've removed your address from the sane-devel mailing-list. JB. -- Julien BLACHE

[sane-devel] [RFC] On libsane symbols visibility

I wish I can find the way to remove my address from the list without giving the pass word Thanks for help francesco --- Ilia Sotnikov wrote: > On 5/8/07, Julien BLACHE wrote: > > "Ilia Sotnikov" wrote: > > > > I don't know if a clean libcheck is > mandatory/enforced as far as > > native win32 i

[sane-devel] [RFC] On libsane symbols visibility

I wish I can find the way to remove my address from the list without giving the pass word Thanks for help francesco --- William Gallafent wrote: > On Tuesday 08 May 2007 16:15:38 Julien BLACHE wrote: > > SANE traditionally builds with non-gcc compilers > too, so this > > is kind of a no-go for th

[sane-devel] [RFC] On libsane symbols visibility

On Tuesday 08 May 2007 16:15:38 Julien BLACHE wrote: > SANE traditionally builds with non-gcc compilers too, so this > is kind of a no-go for the gcc-deprived (or the > gcc-sucks-no-way-I-use-it, YMMV) :) Intel compiler version 9 supports these "-fvisibility" compiler options, on Mac and Linux, I

[sane-devel] [RFC] On libsane symbols visibility

"Ilia Sotnikov" wrote: > As far as I understand, it's not enforced, but highly recommended/good > coding style. Although, if hiding some symbols would introduce a lot > of portability problems, it should be avoided, in my opinion. > > Deciscion: don't introduce additional complexities and let som

[sane-devel] [RFC] On libsane symbols visibility

On 5/8/07, Julien BLACHE wrote: > "Ilia Sotnikov" wrote: > > I don't know if a clean libcheck is mandatory/enforced as far as > native win32 is concerned; I think it can't be avoided if part of the > portable function library is used. As far as I understand, it's not enforced, but highly recomme

[sane-devel] [RFC] On libsane symbols visibility

"Ilia Sotnikov" wrote: > Yes, I saw and used that solution. What about marking symbols > explicitly when compiling under native Windows and use no attributes > under other platforms? Otherwise we'll need to leave with > not-intended-to-but-exported symbols at least under Windows having > 'make li

[sane-devel] [RFC] On libsane symbols visibility

On 5/8/07, Julien BLACHE wrote: > SANE traditionally builds with non-gcc compilers too, so this is kind > of a no-go for the gcc-deprived (or the gcc-sucks-no-way-I-use-it, > YMMV) :) > Then for such compilers we'll definitely need to use some #ifdef's. > Backends that use multiple files usually

[sane-devel] [RFC] On libsane symbols visibility

"Ilia Sotnikov" wrote: > My suggestion is to mark the functions which are part of SANE API as > exportable (__attribute__ ((visibility("default"))) symbol attribute > and its companion, -fvisibility=hidden). It will give us the necessary > result - only explicitly marked symbols will be visible.

[sane-devel] [RFC] On libsane symbols visibility

Doing native Win32 porting and new backend adding I ran into the question about libsane symbols visibility. That's what 'make libcheck' checks. Current libsane model (or better to say, programming conventions) don't allow to export unnecessary symbols from libsane libraries. That's wise because of