> Yes, can you please try with latest gnulib.git plus this patch...
We tried out the patch an no longer see empty include's (i.e. #include
"") appearing. I consider the original bug I reported as fixed. Thank
you.
However, we see some headers including themselves (indirectly or
directly, I'm uns
On 12/04/2013 10:38 AM, Rhys Ulerich wrote:
>> Reviving this thread; I've fixed the code duplication, and now have only
>> one spot to work on to fix Rhys' original complaint.
>
> Thanks Eric. Any tentative fix that I should ask my user to try out
> on that BG system? I'm unsure what to try in l
> Reviving this thread; I've fixed the code duplication, and now have only
> one spot to work on to fix Rhys' original complaint.
Thanks Eric. Any tentative fix that I should ask my user to try out
on that BG system? I'm unsure what to try in light of the reduced
duplication.
- Rhys
On 10/11/2013 09:24 PM, Paul Eggert wrote:
> Eric Blake wrote:
>> Paul, any reason include_next.m4 doesn't reuse absolute-header.m4?
>
> Not that I recall.
Reviving this thread; I've fixed the code duplication, and now have only
one spot to work on to fix Rhys' original complaint.
http://thread.
Eric Blake wrote:
> Paul, any reason include_next.m4 doesn't reuse absolute-header.m4?
Not that I recall.
On 10/11/2013 12:45 PM, Rhys Ulerich wrote:
>
> I pulled gnulib, patched it with the diff modified to use
> 'linux*:bgxlc*', and then ran 'gnulib-tool --update' to try to snarf
> it. Then nothing happened. And I noticed absolute-header.m4 isn't
> populated in my project tree by gnulib-tool. Doe
> Now we just need to modify the .m4
> file to use -C whenever $CC is bgxlc_r.
FWIW, the non-reentrant bgxlc behaves the same way as bgxlc_r with
respect to this float.h issue. Probably worth using 'bgxlc*' for the
patch.
> Does this work for your user?
> I'm a little bit hesitant to key off o
On 10/11/2013 12:11 PM, Rhys Ulerich wrote:
>
>> $ echo '#include ' > foo.c
>> $ bgxlc_r -E foo.c > float.out
>
> This produces a zero-length float.out. My user reports there's no
> float.h file sitting alongside other headers in the usual places.
Makes sense on two fronts - at least with gcc,
On 10/09/2013 03:45 PM, Rhys Ulerich wrote:
>> I will take a stab at this and report back. It may be a couple of days
>> as I don't personally have access to the system.
>
> I'm all thumbs at this. I do see the following suspect differences at
> the tail of that config.log.trimmed I attached pre
> I will take a stab at this and report back. It may be a couple of days
> as I don't personally have access to the system.
I'm all thumbs at this. I do see the following suspect differences at
the tail of that config.log.trimmed I attached previously:
NEXT_ERRNO_H=''
NEXT_FCNTL_H='"///bgsys/dr
>> On Intrepid, a BG/P system up at Argonne with some fun old IBM XL
>> compilers, a user of mine is seeing gnulib/float.h containing the line
>> #include " "
>> which appears to be arising from
>> configure:13477: checking absolute name of
>> configure:13516: result: ""
> The full co
On 10/08/2013 04:13 PM, Rhys Ulerich wrote:
> On Intrepid, a BG/P system up at Argonne with some fun old IBM XL
> compilers, a user of mine is seeing gnulib/float.h containing the line
> #include " "
> which appears to be arising from
> configure:13477: checking absolute name of
> conf
On Intrepid, a BG/P system up at Argonne with some fun old IBM XL
compilers, a user of mine is seeing gnulib/float.h containing the line
#include " "
which appears to be arising from
configure:13477: checking absolute name of
configure:13516: result: ""
due to
http://git.savannah.gnu.
13 matches
Mail list logo
