Hello!
Not really a bug report, IMO, but one of the GDB Maintainers thought
it would be worth mentioning this to you:
Both BFD and GDB use a number of procfs routines, and those routines
are apparently incompatible with largefile support on 32bit solaris
(sparc32, x86).
Ref: https://www.sourcewa
> That's probably a bug in libiconv - POSIX says that EILSEQ and ENOENT
> must be distinct.
[...]
> > In terms of the build error on Lynx178, what I ended up doing
> > was compile with -DEILSEQ=ENOENT.
>
> This smells wrong, but at least it worked for you, while we figure out
> how to fix things p
Hello,
A few weeks ago, I reported a problem to gnulib where the errno
module would still be missing the EILSEQ macro on systems that
do not define it (in this particular case: LynxOS 178):
http://lists.gnu.org/archive/html/bug-gnulib/2012-10/msg00088.html
The problem was solved by defining EILSE
this open like this would allow
us to know for sure if the problem ever came up. I have a feeling
this would only be relevant to older systems anyway.
> +2012-11-05 Paul Eggert
> +
> + errno: port to LynxOS 178 2.2.2
> + Problem reported by Joel Brobecker in
> + <h
00644
> --- a/ChangeLog
> +++ b/ChangeLog
> @@ -1,3 +1,14 @@
> +2012-11-01 Paul Eggert
> +
> + errno: port to LynxOS 178 2.2.2
> + Problem reported by Joel Brobecker in
> + <http://lists.gnu.org/archive/html/bug-gnulib/2012-10/msg00088.html>.
> + * do
Hello,
In trying to compile mbrtowc.c on LynxOS 178, I got an error because
EILSEQ is not defined. Indeed, the system itself is too old, and is
missing that definition.
Initially, I tried to find a way that would be completely generic:
Check errno.h and do nothing if found. Otherwise, check wchar
Hello,
I was trying to cross-compile mbrtowc for a system where EILSEQ
is not defined (C99). The first attempt I made was to import
the errno module, and see if it would define it for me. But no luck.
I am unsure about the best way to fix this issue. The simplest
approach, would probably to chang
> > Yep, this is what we did for this year. I just want to go one step
> > further and just collapse all years into one single range, based on
> > the fact that I have verified that we have made significant changes
> > to at least one file each year since 1986.
>
> I have already done this for som
> Good news: the GCS has been updated to explain that using copyright
> year ranges is now ok. The only conditions are that you perform
>
> https://savannah.gnu.org/forum/forum.php?forum_id=6576
>
> the strict conversion (i.e., "2002,2004" cannot be converted to
> "2002-2004") and that you a
Hi Jim,
> Currently parted work and an imminent coreutils release are taking all of
> my time. Maybe Joel Denny can help? At worst, I'll follow up next week.
This really has no urgency at all. I've done the update for GDB and
we are good for another year.
Also, I am trying to get the OK from t
Hello, and Happy New Year :-).
I am trying to use gnulib's update-copyright script to update all
of GDB's files. It's working quite beautifully, and it's quite fast
too. I only have a couple of issues:
- C files: In GDB, the style for comments is to avoid the '*'
at the start of new files.
Okidoke,
Here is a small status on this thread... Generally speaking, I expect
all issues to be officially resolved soon.
On Fri, Jun 27, 2008 at 03:31:39PM -0400, Joel Brobecker wrote:
> > Boo. And if we change libdecnumber to use gnulib's version we'll
> > undoubt
Hi Bruno,
> > > 2. ctype/safe-ctype conflict. For instance, cp-support.c includes
> > > safe-ctype.h. But at the same time, we previously included
> > > defs.h, which itself includes gnulib/stdint.h, which includes
> > > which includes .
> >
> > > Problem #2 is a lot more probl
> Boo. And if we change libdecnumber to use gnulib's version we'll
> undoubtedly break gcc. If we provide gstdint.h in the gdb directory
> which redirects to , will libdecnumber pick it up at this
> point?
That's pretty ingenious. Indeed, that works, since the include order
when compiling GDB fi
14 matches
Mail list logo
