Re: [PATCH 4/4] Add a test suite for the sethostname module
Excerpts from Bruno Haible's message of Sun Dec 04 13:45:51 -0500 2011: Hi Bruno, > You have been misunderstanding how the C and C++ macro expansion > process works. The only place where a space before the open > parenthesis is not allowed is in the *definition* of a macro with > arguments, like here: Yes, it seems I was mistaken about this. Thanks for the correction and the reference. Thanks for the windows port of this function too! Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302
./lib/getopt.h:197: error: redefinition of `struct option'
Hi,
I'm banging my head against a wall here trying to port nss_db to Solaris 10.
It includes a source file called makedb.c that requires argp.h and error.h.
Incidentally it also requires a Berkeley database which I have in
/opt/csw/bdb48/include/db.h.
I thought the easiest thing was to use gnulib to provide the missing argp and
error functionality. I couldn't get the git repo (firewall restrictions), so
had
to grab the latest package from here: http://erislabs.net/ianb/projects/gnulib/
Unfortunately, by importing these gnulib modules I get a new unistd.h that
includes getopt.h. The Solaris package SUNWhea also has getopt.h, and now the
problems really start.
I imported:
./gnulib-tool --import argp error
and set-up the pre-requisites in configure.in and Makefile.am.
Here is a very simple test file:
#include
int main(int argc, char **argv)
{
return 0;
}
The following works fine:
$ gcc -I/opt/csw/bdb48/include testme.c
But if the 'lib' directory is included, it breaks:
$ gcc -I./lib -I/opt/csw/bdb48/include testme.c
In file included from ./lib/unistd.h:112,
from /opt/csw/bdb48/include/db.h:29,
from testme.c:1:
./lib/getopt.h:197: error: redefinition of `struct option'
I can only assume that the redefinition of struct option comes from the other
getopt.h, but maybe I'm barking up the wrong tree here because I can't figure
out
how that would be included in my build anyway:
$ grep getopt.h /usr/include/*.h /usr/include/*/*.h
/usr/include/getopt.h:#pragma ident "@(#)getopt.h 1.1 04/03/29 SMI"
Can someone advise? How do I get rid of this error?
Thanks in advance,
Mark.
Re: ./lib/getopt.h:197: error: redefinition of `struct option'
On 12/06/2011 04:58 AM, Mark R Bannister wrote: > Hi, > > I'm banging my head against a wall here trying to port nss_db to Solaris 10. > > It includes a source file called makedb.c that requires argp.h and error.h. > Incidentally it also requires a Berkeley database which I have in > /opt/csw/bdb48/include/db.h. > > I thought the easiest thing was to use gnulib to provide the missing argp and > error functionality. I couldn't get the git repo (firewall restrictions), so > had > to grab the latest package from here: > http://erislabs.net/ianb/projects/gnulib/ > > Unfortunately, by importing these gnulib modules I get a new unistd.h that > includes getopt.h. The Solaris package SUNWhea also has getopt.h, and now the > problems really start. Gnulib getopt should work just fine alongside SUNWhea, if you use it correctly. > > I imported: > ./gnulib-tool --import argp error > and set-up the pre-requisites in configure.in and Makefile.am. > > Here is a very simple test file: > > #include There's your problem. You have to #include prior to any other include files, if you want gnulib's getopt replacements to work. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: ./lib/getopt.h:197: error: redefinition of `struct option'
On Tue 06/12/11 13:56 , Eric Blake ebl...@redhat.com sent: > There's your problem. You have to #include prior to any > other include files, if you want gnulib's getopt replacements to work. Thanks Eric, that worked. May I suggest that gnulib-tool is improved to check that a) config.h is being generated and if not advise the user on how to get it to be created in the first place and b) advise the user to #include the config.h header. Thanks again, Mark.
restrictive umask vs gnupload
I use a umask of 077. That is rather irregular (022 is more common), but for a good reason. It might have saved me from exploit via at least one flaw (the automake "dist" abuse CVE). Anyhow, many tools fail to account for the possibility of a restrictive umask, and gnupload is one of them. If I'm not careful, gnupload will create a .sig file that is neither group- nor world-writable (0600 permissions). In some contexts, if I upload and preserve those permissions, the file will be inaccessible. I have a few ways to avoid that: - change gnupload to set umask 022 - change gnupload to run chmod go+r on each uploaded file (may not always be appropriate?) - temporarily set umask 022 before running gnupload (which would mean changing the gnupload command that maint.mk emits, - "remember" always to set permissions of files I'm uploading so that they include go+r - set umask 022 via a .gnuploadrc file in every build directory So far, this happens only when I make gnupload use scp (i.e., not to ftp.gnu.org). I'd prefer to change gnupload. The umask-in-gnupload change would fix it only for .sig, but unless I'm careful, the .tar.xz file is also go-r, so from that perspective, the chmod go+r would be better. You can argue that this whole problem would go away if I would just use (umask 022; make stable), but that is exactly the context in which I did not want to use a permissive umask. However, now that all of my working directories are go-rwx, it should be mostly moot. But you never know when some tool you run might decide to create a directory in /tmp ... Opinions, preferences, "get over it!" ;-)
Re: restrictive umask vs gnupload
On 12/06/11 12:37, Jim Meyering wrote: I use a umask of 077. That is rather irregular Opinions, preferences, "get over it!" ;-) gnupload is responsible for delivering the files to GNU in a workable fashion regardless of your personal preferences. What it ought to really do is check for go+r on the files it is about to transmit. If not set, the bits should be set before transmission and reset afterward. That would be the excruciatingly correct way to do it. :)
Re: restrictive umask vs gnupload
On 12/06/2011 01:37 PM, Jim Meyering wrote: > I have a few ways to avoid that: > - change gnupload to set umask 022 > - change gnupload to run chmod go+r on each uploaded file (may not > always be appropriate?) > I'd prefer to change gnupload. Agreed. Either of the two changes I highlighted above seem reasonable; although the second seems to me to be less prone to failure (changing the umask affects new files, but not existing files with too-tight restrictions), and I can't think of any useful scenario where you _want_ gnupload to push a restrictive permission file into a public location (after all, the point of using gnupload is to share a file with the public) > Opinions, preferences, "get over it!" ;-) Definitely worth a patch. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
