Re: Intel 2016.1.150 compilation problems

On 03/16/2016 12:04 AM, Balazs Hajgato wrote: Well, Intel compiler says that C99 or C11 is C, and not C++. So I am not able to request C99 or C11 for C++ programs. In that case, why is Gnulib not using the equivalent of "#define restrict /* empty */" so that the rest of the code can use 'restric

[PATCH] early check for PowerPC AIX object mode

Native PowerPC AIX tools do accept only 32 bit objects by default. They either need the -X32_64 commandline flag to accept both, or the OBJECT_MODE=64 environment variable to switch to accepting 64 bit objects only, while the GNU toolchain ignores both the -X32_64 flag and the environment variable.

Re: Issues with progname

On Friday 18 March 2016 09:52:08 Paul Eggert wrote: > On 03/18/2016 09:47 AM, Pino Toscano wrote: > > That works for me too, both for license and API -- but should progname > > be rewritten (breaking users of it), or add a new getprogname module? > How about if we (1) add a new getprogname module,

Re: Issues with progname

On 03/18/2016 10:10 AM, Pino Toscano wrote: I fully agree with your (1) and (3), as they match what I also proposed earlier. Regarding (2), I'm not sure that a getprogname()-like interface could work with the existing progname. I'd put that as second step for now, and if it turns out to not wor

Issues with progname

Hi, (please CC me, I'm not subscribed) while porting libguestfs (which uses gnulib) to FreeBSD, I noticed issues due to program_name. Namely, we don't use it directly, but some of the used gnulib modules do, leading to undefined references. gnulib provides a 'progname' module, but at least to m

Re: Issues with progname

On 03/18/2016 09:47 AM, Pino Toscano wrote: That works for me too, both for license and API -- but should progname be rewritten (breaking users of it), or add a new getprogname module? How about if we (1) add a new getprogname module, (2) modify progname to use it (without breaking progname's AP

[PATCH] test-userspec.c: do not trigger gcc's new -Wmisleading-indentation

I build the latest gcc from git regularly, to ensure it can still build the tools I care about still build from source and the resulting binaries still do pass their tests. Here's an instance in which, when configured with --enable-gcc-warnings, one of coreutils' tests (inherited from gnulib) fail

Problem with sys_select on Cygwin

Cygwin is changing its headers as of the next release so that sys/types.h includes sys/select.h. This is incompatible with Gnulib's sys_select module. If a Gnulib module includes sys/types.h, this brings in Gnulib's sys/select.h, which includes signal.h and other system headers. Since the in

Re: Issues with progname

On 03/18/2016 09:08 AM, Pino Toscano wrote: progname is GPL 3+, which means it cannot be used in the main library (which is LGPL 2) without changing the license of the resulting work. I expect this is because it was intended to be used only by programs, not by libraries, so GPL was appropriate

Re: gnulib and MSVC

Bruno Haible writes: > Paul Eggert wrote: >> As I understand it hey can either run the autotools on some other >> platform and then copy the files to an MSVC host, or run the autotools >> in MSVC (see ). > You find the relevant scripts attached. ms

Re: Problem with sys_select on Cygwin

Ken Brown wrote: Cygwin is changing its headers as of the next release so that sys/types.h includes sys/select.h Can sys_select be changed so that it doesn't try to include other headers before it has finished including sys/types.h? Or is there some other way to solve this problem? Probabl

Re: Intel 2016.1.150 compilation problems

I think i am not able to do that. The case is currently investigated by Intel, lets see what they will get. https://software.intel.com/en-us/forums/intel-c-compiler/topic/612811 Additionally, the previous version of Intel com

Re: Issues with progname

On Friday 18 March 2016 09:38:30 Paul Eggert wrote: > On 03/18/2016 09:08 AM, Pino Toscano wrote: > > progname is GPL 3+, which means it cannot be used in the main library > > (which is LGPL 2) without changing the license of the resulting work. > > I expect this is because it was intended to be u