Re: [PATCH] * lib/safe-alloc.h (__GNUC_PREREQ): define if not already defined

David Lutterkort wrote: > lib/safe-alloc.h |9 + Thanks, I applied it for you, with this ChangeLog entry: 2009-03-02 David Lutterkort * lib/safe-alloc.h (__GNUC_PREREQ): New macro. Reported by Tom G. Christensen .

Re: safe-alloc.h uses __GNUC_PREREQ without defining it

On Sat, 2009-02-28 at 14:56 +0100, Tom G. Christensen wrote: > Building the latest snapshot on sparc-sun-solaris2.6 fails: > In file included from safe-alloc.c:27: > safe-alloc.h:30:21: error: missing binary operator before token "(" > make[4]: *** [safe-alloc.o] Error 1 > > It seems __GNUC_PREREQ

[PATCH] * lib/safe-alloc.h (__GNUC_PREREQ): define if not already defined

--- lib/safe-alloc.h |9 + 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/lib/safe-alloc.h b/lib/safe-alloc.h index 3fa3f2e..f07ee91 100644 --- a/lib/safe-alloc.h +++ b/lib/safe-alloc.h @@ -26,6 +26,15 @@ # include +#ifndef __GNUC_PREREQ +# if defined __GNUC__ &&

Re: exported symbols of shared libraries

Paolo Bonzini wrote: > Well, then using __attribute__ ((visibility ("hidden"))) is more > efficient, and right now almost all GCC users should have switched to > 3.1 or later... The better approach (IMO) is the third one mentioned in doc/visibility.texi, namely to mark every exported function/vari

Re: exported symbols of shared libraries

Ralf Wildenhues wrote: > How about suggesting libtool's -export-symbols as a more portable but > less powerful alternative for systems that do not support GNU ld version > scripts? I'm applying this doc patch to mention -export-visibility in the gnulib doc. But as you can see from this doc section

Re: [PATCH] announce-gen: new option: --no-print-checksums

Simon Josefsson writes: > Btw, is there any point in publishing MD5 checksums? It depends on your threat model. If the threat is a sophisticated, malicious adversary, then there is little point in publishing MD5 checksums. If the threat is accidental corruption during a file transfer, then MD5

Re: linker-script.m4?

> How about suggesting libtool's -export-symbols as a more portable but > less powerful alternative for systems that do not support GNU ld version > scripts? Alternatively, of course support for, say, Solaris ld version > scripts would be nice too. Well, then using __attribute__ ((visibility ("h

Re: linker-script.m4?

On Monday 02 March 2009 06:27:49 Bruno Haible wrote: > Simon Josefsson wrote: > > The version script file is documented in the LD manual, but a short > > example would be: > > > > SHISHI_0.0 { > > global: > > shishi*; > > > > local: > > *; > > }; > > Could you please explain what the en

Re: shared library symbol exports and versioning

Simon, > However, do you object to installing the original module to gnulib? Now that you have shown that it provides access to functionality that libtool does not provide portably, I don't object. But I would find it useful to revise the doc and the module name 1) in order to clarify that it's

Re: shared library symbol exports and versioning

Bruno Haible writes: > Simon Josefsson wrote: >> I won't dispute that ELF version symbol scripts are overrated because >> they aren't portable. But they do provide some features, and together >> with a scheme like you suggest you get more complete cross-platform >> versioning. > > ... at the cos

Re: shared library symbol exports and versioning

Simon Josefsson wrote: > I won't dispute that ELF version symbol scripts are overrated because > they aren't portable. But they do provide some features, and together > with a scheme like you suggest you get more complete cross-platform > versioning. ... at the cost of maintaining the same inform

Re: shared library symbol versioning

Bruno Haible writes: > So here we have the classical dilemma between use of advanced GNU tools > and glibc features, vs. portability. > > The portable way to do symbol versioning is through the include file. > In libgettextpo I have this declaration: > > #define po_file_read po_file_read_v3 >

Re: linker-script.m4?

Ralf Wildenhues writes: > Hi Simon, > > * Simon Josefsson wrote on Mon, Mar 02, 2009 at 11:02:44AM CET: >> --- /dev/null >> +++ b/doc/linker-script.texi >> @@ -0,0 +1,26 @@ >> +...@node Library Version Scripts >> +...@section Library Version Scripts >> + >> +The @code{linker-script} module can be

Re: shared library symbol versioning

Simon Josefsson wrote: > > Or is it about allowing multiple versions of the same symbol to exist > > in the same shared library, something which is supported only by glibc > > and Solaris [2]? > > Yes, that is one reason. > > > I'm asking because linker scripts only work with GNU ld (I guess). >

Re: linker-script.m4?

Bruno Haible writes: > Simon Josefsson wrote: >> The version script file is documented in the LD manual, but a short >> example would be: >> >> SHISHI_0.0 { >> global: >> shishi*; >> >> local: >> *; >> }; > > Could you please explain what the entire thing is about? Is it about > hid

Re: linker-script.m4?

Hi Simon, * Simon Josefsson wrote on Mon, Mar 02, 2009 at 11:02:44AM CET: > --- /dev/null > +++ b/doc/linker-script.texi > @@ -0,0 +1,26 @@ > +...@node Library Version Scripts > +...@section Library Version Scripts > + > +The @code{linker-script} module can be used to add shared library > +version

Re: linker-script.m4?

Simon Josefsson wrote: > The version script file is documented in the LD manual, but a short > example would be: > > SHISHI_0.0 { > global: > shishi*; > > local: > *; > }; Could you please explain what the entire thing is about? Is it about hiding some symbols from "nm libshishi.so",

Re: linker-script.m4?

Here is a complete patch, including documentation. It also avoids the need to modify configure.ac. Sorry for spamming. Objections? /Simon >From ef0300261126cdf57471b36317b84f4d48a3af13 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Mon, 2 Mar 2009 11:02:16 +0100 Subject: [PATCH] linker-

Re: linker-script.m4?

The gnulib manual would also be amended to describe how to use the module, along the following lines. You need to add to configure.ac this line: gl_LINKER_SCRIPT([$srcdir/lib/shishi.vers]) And in Makefile.am add something like this: if HAVE_LD_VERSION_SCRIPT libshishi_la_LDFLAGS += -Wl,--versio

linker-script.m4?

In many of my library projects, I use shared library versioning when possible. This requires some M4 magic to detect the necessary parameters. I've been using this M4 macro for some time now. What do you think about including this in gnulib? Thoughts on better ways to achieve the same thing? /

Re: [PATCH] announce-gen: new option: --no-print-checksums

Jim Meyering writes: > I've been manually removing MD5 and SHA1 checksums from the template > generated by coreutils' "make alpha/beta/major", so have added this > so I can automate it: Btw, is there any point in publishing MD5 checksums? MD5 was considered broken many years ago. I publish SHA

Re: [PATCH] setsockopt: Add support for timeouts on W32

Bruno Haible writes: > In this thread, there was also the proposed patch to use 'socklen_t' instead > of 'int' in the prototypes of getsockopt() and setsockopt(). > > Paolo approved it, Simon did not object, I had tested it on