On 06/10/11 11:37, Bruno Haible wrote:
> Hi,
>
> Markus Duft wrote:
>> long long double is broken.
>
> You surely mean "long double"? There is no such type as "long long double"
> in C.
>
>> this bites me in the gnulib vasnprintf implementation, which calls snprintf
>> from libc which immediatel
> openat: Work around compilation error with OSF/1 5.1 DTK cc.
Once this problem resolved, the build stops with a link error:
gmake[1]: Entering directory
`/home/haible/multibuild-1227/osf51-cc/coreutils-8.12.193-d8dc8/src'
CC sort.o
CCLD sort
ld:
Unresolved:
__pthread_mutex_
Paul Eggert wrote:
> On 09/07/11 02:49, Bruno Haible wrote:
> > -#include
> > +/* Write "fcntl.h" here, not , otherwise OSF/1 5.1 DTK cc
> > miscompiles
> > + openat.c because that file has a preliminary #include . */
> > +#include "fcntl.h"
>
> Thanks. Is a similar change needed to lib/open
On 7 September 2011 22:33, Bruno Haible wrote:
>
> For crypt() to be declared in , you need nothing.
But neither crypt(3) nor crypt(3posix) documents accessing crypt via
#include , which suggests that's a non-standard way to get
the function.
> Note that must be the first header file to be incl
Hi Reuben,
> I find that some APIs on GNU systems need
> extra treatment (i.e. GNU is not POSIX-1.2001 by default). For
> example, for crypt(3) I need to define _XOPEN_SOURCE
For crypt() to be declared in , you need nothing. But for it to
be declared in , you need _XOPEN_SOURCE or _GNU_SOURCE.
_G
Trying to build some code (Lua bindings for POSIX APIs) with a
gnulib-ized build system, I find that some APIs on GNU systems need
extra treatment (i.e. GNU is not POSIX-1.2001 by default). For
example, for crypt(3) I need to define _XOPEN_SOURCE, and for some
realtime functions such as clock_getre
Bumping this thread back to the top of the pile for it's 1 month anniversary...
On 24 Aug 2011, at 00:51, Gary V. Vaughan wrote:
> Hi Paul,
>
> Just want to keep this on your radar...
>
> Also, please note that I've made some small improvements to the script,
> and pushed to the GNU Zile reposi
On 09/07/11 11:01, Gary V. Vaughan wrote:
>> static inline char *
>> > my_tigetstr (char const *capname)
>> > {
>> > return tigetstr ((char *) capname);
>> > }
>> > #undef tigetstr
>> > #define tigetstr my_tigetstr
> Not that I've tried it, but surely you now get a warning in every file
> that in
Hi Paul, Reuben,
On 7 Sep 2011, at 21:18, Paul Eggert wrote:
> On 09/07/11 04:55, Reuben Thomas wrote:
>> For example, from terminfo:
>> char *tigetstr (char *capname);
>> So, what's a hacker to do?
>
> If we're talking C, you can put this into your
> application's system.h file:
>
> static inli
On 09/07/11 02:49, Bruno Haible wrote:
> -#include
> +/* Write "fcntl.h" here, not , otherwise OSF/1 5.1 DTK cc
> miscompiles
> + openat.c because that file has a preliminary #include . */
> +#include "fcntl.h"
Thanks. Is a similar change needed to lib/open.c,
which plays the same trick with
On 09/07/11 04:55, Reuben Thomas wrote:
> For example, from terminfo:
> char *tigetstr (char *capname);
> So, what's a hacker to do?
If we're talking C, you can put this into your
application's system.h file:
static inline char *
my_tigetstr (char const *capname)
{
return tigetstr ((char *) cap
Bruno Haible wrote:
> Hi Jim, Paul,
>
>> I hope to be able to make the coreutils-8.13 release on Wednesday.
>
> There is a regression: A new compilation error on OSF/1 5.1.
>
> CC openat.o
> cc: Error: openat.h, line 59: In this statement, "AT_SYMLINK_NOFOLLOW" is not
> declared. (undecla
I like warnings, I like to turn them all on, and I like to use
--enable-gcc-warnings to force them on my attention.
And then just occasionally the warnings are misguided. One example is
old APIs. For example, from terminfo:
char *tigetstr (char *capname);
So, one can't call, e.g. tigetstr("kbs")
On 2011-09-07 13:22:09 +0200, Simon Josefsson wrote:
> Vincent, Bruno, if you can think of ways of making the situation better
> even for projects that use libtool wrappers of self-tests, then let's do
> that too -- I'm just mentioning that -no-install may be a solution.
Yes, I think this should b
Another solution is to put
AM_LDFLAGS = -no-install
in the Makefile.am of your self-test directory, so libtool will not
build wrappers for them.
I have not seen any negative effects of doing this, and it helps
significantly with issues like this (especially for running gdb).
Vincent, Bruno, if
Bruno Haible wrote:
> This is an automated email from the git hooks/post-receive script. It was
> generated because a ref change was pushed to the repository containing
> the project "gnulib - GNU portability library".
>
> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=76074e9af140661560
Hi Jim, Paul,
> I hope to be able to make the coreutils-8.13 release on Wednesday.
There is a regression: A new compilation error on OSF/1 5.1.
CC openat.o
cc: Error: openat.h, line 59: In this statement, "AT_SYMLINK_NOFOLLOW" is not
declared. (undeclared)
return fchownat (fd, file, o
17 matches
Mail list logo
