New(!?) warning makes configure for 21.4 break

[Mats Lidell]

Hi,

It seems like from some version of glibc, mid April on the buildbot machine, there is this warning when compiling:

# warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"

I suspect that this makes configure fail at finding "X11/Intrincis.h" for 21.4. In 21.5 we seem to have a completely different way to check for this headerfile that is not upset by some little warnings.

This is, or will be, a show stopper for 21.4 on Gentoo at least. What is the right thing to do here? Go over our code and get rid of or replace the defines according to what the warning suggests or make the configure check more robust when it comes to warnings or maybe both?

Yours

[Stephen J. Turnbull]

Post by Mats Lidell
This is, or will be, a show stopper for 21.4 on Gentoo at
least. What is the right thing to do here? Go over our code and get
rid of or replace the defines according to what the warning
suggests or make the configure check more robust when it comes to
warnings or maybe both?

I'm not sure we should do anything (Vin really wants to stop
maintaining 21.4), but if we do my vote is +1 for fixing the configure
checks and -1 on the code changes. It's not clear that those changes
would be trivial, especially if we have any code that does something
different #ifdef _BSD_SOURCE than for #ifdef _SVID_SOURCE.

But we may not have a choice, as configure.in is long obsolete, and I
suspect many distributions may stop supporting autoconf 2.13 in the
nearish future.

Steve

[Mats Lidell]

Post by Stephen J. Turnbull
I'm not sure we should do anything (Vin really wants to stop
maintaining 21.4),

Yes, I know, but these types of changes pulls the rug from under our
feet. So in an ever changing world this will happen.

A fix for gentoo would be to just patch configure with a -Wno-cpp
command line option on the test for Intrinsic.h. That will fix the
current situation with the ebuild failing. (I have verified that it
works so I might go for that for a quick fix.)

If this is a good pragmatic solution is another deal. If the glibc
warning in later versions turns into something that will break the
compile we are there again. But I haven't read up enough why this
warning was introduced in glibc in the first place so I can't imagine
what the future will bring in this respect.

Yours

[Vin Shelton]

Hi, Mats!

Post by Mats Lidell
Yes, I know, but these types of changes pulls the rug from
under our feet. So in an ever changing world this will happen.

... and I have been unable to compile 19.16 on any linux box for several
years. So?

I am not trying to be flippant (well OK, just a tad), but time marches on.
As Stephen pointed out, configure.in has been obsolete for quite a long
time now. I am sure there are other ancient technologies incorporated into
21.4 (we had to make changes with newer versions of gcc, IIRC), but we need
to declare 21.4 frozen and not move that codebase forward.

If you want to keep building 21.4 for gentoo, please make adjustments for
the frozen 21.4 sources in the gentoo build system.

Can we please promote 21.5 to stable sometime?

Cheers!
Vin

[Mats Lidell]

Hi Vin,

... and I have been unable to compile 19.16 on any linux box for several years.  So?

Well 21.4 is still the stable version.

[...] but we need to declare 21.4 frozen and not move that codebase
forward.

Agreed!

If you want to keep building 21.4 for gentoo, please make
adjustments for the frozen 21.4 sources in the gentoo build system.

Yes that is what I plan.

Maybe(!?) compile-from-source distros, like Gentoo, have more problems
with this since the problem immediately hits the users. Since it does
not only affect new installs of xemacs but also if for some reason it
needs to be rebuilt.

Can we please promote 21.5 to stable sometime?

Yes that would be nice. It would remove the pressure on xemacs-21.4
and line it up with 19.16 in the archives.

Yours

[Vin Shelton]

Dear Mats,

Thank you for your gentle and thoughtful response to my (perhaps hasty and
ill-tempered) reply

Post by Vin Shelton

Post by Vin Shelton
... and I have been unable to compile 19.16 on any linux box for several

years. So?
Well 21.4 is still the stable version.

Right. That, specifically, is the crux of the matter.

Post by Vin Shelton
[...] but we need to declare 21.4 frozen and not move that codebase

Post by Vin Shelton
forward.

Agreed!

Post by Vin Shelton
If you want to keep building 21.4 for gentoo, please make
adjustments for the frozen 21.4 sources in the gentoo build system.

Yes that is what I plan.

Great!

Post by Vin Shelton
Maybe(!?) compile-from-source distros, like Gentoo, have more problems
with this since the problem immediately hits the users. Since it does
not only affect new installs of xemacs but also if for some reason it
needs to be rebuilt.

That could well be. For instance, I have not seen any problem on my Mint
systems.

But the from-source distros need up-to-date tools to support building
packages. autoconf 2.13 ain't it.

Post by Vin Shelton

Post by Vin Shelton
Can we please promote 21.5 to stable sometime?

Yes that would be nice. It would remove the pressure on xemacs-21.4
and line it up with 19.16 in the archives.

:-)

Best,
Vin

[Stephen J. Turnbull]

I will likely continue to use and maintain 21.4 for myself for some
time. If someone else would like to benefit, that's fine with me, and
I can coordinate with downstream package maintainers.

I believe that Martin Buchholz <***@xemacs.org> is in a similar
situation, though I haven't talked with him about XEmacs maintenance
for years. But he might have patches or improvements you'd be
interested in.

[Mats Lidell]

Post by Vin Shelton
If you want to keep building 21.4 for gentoo, please make
adjustments for the frozen 21.4 sources in the gentoo build system.

The fix was easy. Run configure with cpp-flags set to -Wno-cpp that
disables cpp warnings.

I guess we can recommend that work-around to those who get into
this!?. Can we hope that 21.5 is stable at the time glibc turn this
into an error?

Note that 21.5 is also affected by these warnings but the configure
step handles it better there.

Yours

[Stephen J. Turnbull]

Post by Mats Lidell
I guess we can recommend that work-around to those who get into
this!?. Can we hope that 21.5 is stable at the time glibc turn this
into an error?

We can certainly declare it "stable" by then. At current pace, it
won't be stable, though. :-(

Post by Mats Lidell
Note that 21.5 is also affected by these warnings

Of course.

Post by Mats Lidell
but the configure step handles it better there.

I think that's to be expected since autoconf 2.13 was frozen long
before these warnings were even possible :-) while 21.5 uses
up-to-date autoconf (2.59 is a lower bound but I think we actually
require something in the low-to-mid 2.60s).

Steve