Installing XEmacs under Cygwin

[Dr Rainer Woitok]

Greetings,

not sure whether or not this is the right list ... but here goes anyway:

Since a few days I'm trying in vain to install XEmacs under Cygwin. I
have freshly cloned the source repository from

https://bitbucket.org/xemacs/xemacs

and I have freshly updated Cygwin to its latest release. The problem
starts when compiling "src/alloc.c":

gcc -c -Wall -Wno-switch -Wundef -Wsign-compare -Wno-char-subscripts -Wpacked -Wpointer-arith -Wshadow -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wdeclaration-after-statement -Wunused-parameter -g -Demacs -I. -I/home/Rainer/repo/xemacs/src -DHAVE_CONFIG_H -fno-caller-saves alloc.c
In file included from events.h:574:0,
from alloc.c:49:
/usr/include/w32api/winnt.h:5170:15: error: two or more data types in declaration specifiers
DWORD64 Status;
^
/usr/include/w32api/winnt.h:5309:13: error: two or more data types in declaration specifiers
DWORD Status;
^
/usr/include/w32api/rpcdce.h:142:88: error: expected ';', ',' or ')' before 'int'
typedef void __RPC_API RPC_OBJECT_INQ_FN(UUID *ObjectUuid,UUID *TypeUuid,RPC_STATUS *Status);
^
In file included from /usr/include/w32api/rpc.h:82:0,
from /usr/include/w32api/wtypes.h:7,
from /usr/include/w32api/accctrl.h:10,
from /usr/include/w32api/aclapi.h:14,
from syswindows.h:206,
from sysfile.h:95,
from alloc.c:61:
/usr/include/w32api/rpcdce.h:210:51: error: unknown type name 'RPC_OBJECT_INQ_FN'
RPCRTAPI RPC_STATUS RPC_ENTRY RpcObjectSetInqFn(RPC_OBJECT_INQ_FN *InquiryFn);
^
In file included from events.h:574:0,
from alloc.c:49:
/usr/include/w32api/rpcdce.h:471:145: error: expected ';', ',' or ')' before 'int'
typedef void (__RPC_API *RPC_AUTH_KEY_RETRIEVAL_FN)(void *Arg,unsigned short *ServerPrincName,unsigned __LONG32 KeyVer,void **Key,RPC_STATUS *Status);
^
In file included from /usr/include/w32api/rpc.h:82:0,
from /usr/include/w32api/wtypes.h:7,
from /usr/include/w32api/accctrl.h:10,
from /usr/include/w32api/aclapi.h:14,
from syswindows.h:206,
from sysfile.h:95,
from alloc.c:61:
/usr/include/w32api/rpcdce.h:473:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN'
RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoA(RPC_CSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg);
^
/usr/include/w32api/rpcdce.h:474:112: error: unknown type name 'RPC_AUTH_KEY_RETRIEVAL_FN'
RPCRTAPI RPC_STATUS RPC_ENTRY RpcServerRegisterAuthInfoW(RPC_WSTR ServerPrincName,unsigned __LONG32 AuthnSvc,RPC_AUTH_KEY_RETRIEVAL_FN GetKeyFn,void *Arg);
^
In file included from events.h:574:0,
from alloc.c:49:
/usr/include/w32api/rpcdce.h:513:81: error: expected ';', ',' or ')' before 'int'
RPCRTAPI signed int RPC_ENTRY UuidCompare(UUID *Uuid1,UUID *Uuid2,RPC_STATUS *Status);
^
/usr/include/w32api/rpcdce.h:515:72: error: expected ';', ',' or ')' before 'int'
RPCRTAPI int RPC_ENTRY UuidEqual(UUID *Uuid1,UUID *Uuid2,RPC_STATUS *Status);
^
/usr/include/w32api/rpcdce.h:516:69: error: expected ';', ',' or ')' before 'int'
RPCRTAPI unsigned short RPC_ENTRY UuidHash(UUID *Uuid,RPC_STATUS *Status);
^
/usr/include/w32api/rpcdce.h:517:59: error: expected ';', ',' or ')' before 'int'
RPCRTAPI int RPC_ENTRY UuidIsNil(UUID *Uuid,RPC_STATUS *Status);
^
/usr/include/w32api/rpcdce.h:547:140: error: expected ';', ',' or ')' before 'int'
typedef int (__RPC_API *RPC_MGMT_AUTHORIZATION_FN)(RPC_BINDING_HANDLE ClientBinding,unsigned __LONG32 RequestedMgmtOperation,RPC_STATUS *Status);
^
In file included from /usr/include/w32api/rpc.h:82:0,
from /usr/include/w32api/wtypes.h:7,
from /usr/include/w32api/accctrl.h:10,
from /usr/include/w32api/aclapi.h:14,
from syswindows.h:206,
from sysfile.h:95,
from alloc.c:61:
/usr/include/w32api/rpcdce.h:555:59: error: unknown type name 'RPC_MGMT_AUTHORIZATION_FN'
RPCRTAPI RPC_STATUS RPC_ENTRY RpcMgmtSetAuthorizationFn(RPC_MGMT_AUTHORIZATION_FN AuthorizationFn);
^
In file included from events.h:574:0,
from alloc.c:49:
/usr/include/w32api/rpcdcep.h:220:62: error: two or more data types in declaration specifiers
RPCRTAPI __LONG32 RPC_ENTRY I_RpcMapWin32Status(RPC_STATUS Status);
^
/usr/include/w32api/rpcasync.h:118:11: error: two or more data types in declaration specifiers
ULONG Status;
^
/usr/include/w32api/rpcnsip.h:21:81: error: two or more data types in declaration specifiers
RPCNSAPI void RPC_ENTRY I_RpcNsRaiseException(PRPC_MESSAGE Message,RPC_STATUS Status);
^
/usr/include/w32api/rpcndr.h:691:160: error: two or more data types in declaration specifiers
RPCRTAPI RPC_STATUS RPC_ENTRY NdrMapCommAndFaultStatus(PMIDL_STUB_MESSAGE pStubMsg,unsigned __LONG32 *pCommStatus,unsigned __LONG32 *pFaultStatus,RPC_STATUS Status);
^
/usr/include/w32api/aclapi.h:20:58: error: two or more data types in declaration specifiers
typedef VOID (*FN_PROGRESS) (LPWSTR pObjectName, DWORD Status, PPROG_INVOKE_SETTING pInvokeSetting, PVOID Args, WINBOOL SecuritySet);
^
In file included from sysfile.h:95:0,
from alloc.c:61:
syswindows.h:216:18: error: expected identifier or '(' before 'int'
# define Status int
^
In file included from alloc.c:41:0:
alloc.c: In function 'Fmake_byte_code':
lisp.h:2173:23: warning: value computed is not used [-Wunused-value]
((((len & 1) != 0) && (tortoise = XCDR (tortoise), 0)), \
^

I cannot even decide whether this is an XEmacs problem, a Cygwin prob-
lem, or my own problem, in that I'm missing some Cygwin package. Brows-
ing the FAQ and the other XEmacs documentation I found a hint to "in-
stall XFree86, which is available as part of the standard Cygwin in-
stallation", but when I searched the Cygwin packages for "XFree86" I on-
ly got a single match for a package which dates back to 2003 and which
is no longer installable via Cygwin's "setup*.exe". Besides, most (but
not all) libraries originally provided by this package are already in-
stalled in "/usr/lib/" as "*.dll.a" type libraries. Maybe, this part of
the XEmacs documentation is simply outdated.

Anyway, I would be really glad for any pointers shedding some light on
what's wrong or missing here.

Sincerely
Rainer

[Henry S. Thompson]

For 32-bit Cygwin, there is a working package.

Under 64-bit compilation of the current publicly available sources is
known not to work. I have a working set of patches, search the
archive of this list. These have not been official integrated because
I have not yet been able to get a compilation with a freely-available
Microsoft compiler to work.

ht

[Mats Lidell]

These have not been official integrated because I have not yet been
able to get a compilation with a freely-available Microsoft compiler
to work.

Do we really need that in order to push the fix for 64 bit cygwin?
Freely available Microsoft compiler sounds like the native build to
me (which is another deal than the cygwin build right?)

Anyway. I'm back in office next week and can then assist better in
these issues when I get in front of my windows work machine where I
have both environments available.

Yours

[Henry S. Thompson]

Post by Mats Lidell

These have not been official integrated because I have not yet been
able to get a compilation with a freely-available Microsoft compiler
to work.

Do we really need that in order to push the fix for 64 bit cygwin?

That was my understanding of Vin's comments back in April, yes.

Post by Mats Lidell
Freely available Microsoft compiler sounds like the native build to
me (which is another deal than the cygwin build right?)

Yes and yes.

Post by Mats Lidell
Anyway. I'm back in office next week and can then assist better in
these issues when I get in front of my windows work machine where I
have both environments available.

That would be great.

Thanks,

ht

[Vin Shelton]

Dear Henry, Mats et al,

Post by Henry S. Thompson

Post by Mats Lidell

These have not been official integrated because I have not yet been
able to get a compilation with a freely-available Microsoft compiler
to work.

Do we really need that in order to push the fix for 64 bit cygwin?

That was my understanding of Vin's comments back in April, yes.

Post by Mats Lidell
Freely available Microsoft compiler sounds like the native build to
me (which is another deal than the cygwin build right?)

Yes and yes.

I don't think breaking the 32-bit Windows native build in order to build
the 64-bit Cygwin build is progress.

That said, I very much want to be able to build with a more modern
compiler, so if I could get the native Windows build to work with the
(newly-released!!) VS_community, I think our chances of getting a set of
sources which will build both natively and on Cygwin go up. My goal was to
port to the latest freely-available VS (now 2015) this summer. Taking a
new job has slowed my progress on this, but I still think it's achievable.

Post by Henry S. Thompson

Post by Mats Lidell
Anyway. I'm back in office next week and can then assist better in
these issues when I get in front of my windows work machine where I
have both environments available.

That would be great.

Agreed.

- Vin

[Henry S. Thompson]

This post might be inappropriate. Click to display it.

[Henry S. Thompson]

Post by Henry S. Thompson
I checked, and there are a number of other places where system-type
is checked for cygwin32, mostly in conjunction with windows-nt. My
_guess_ is that most if not all of these should be changed to
include cygwin64. Thoughts?

So I wonder if we shouldn't actually replace cygwin32 with cygwin, and
not distinguish 32-bit from 64-bit. Neither windows-nt nor linux nor,
as far as I can see, any of the other systems, distinguish 32-bit from
64-bit.

ht

[Mats Lidell]

Post by Henry S. Thompson
So I wonder if we shouldn't actually replace cygwin32 with cygwin,
and not distinguish 32-bit from 64-bit.

Sounds good to me.

Yours

[Henry S. Thompson]

Post by Henry S. Thompson

Post by Henry S. Thompson
I checked, and there are a number of other places where system-type
is checked for cygwin32, mostly in conjunction with windows-nt. My
_guess_ is that most if not all of these should be changed to
include cygwin64. Thoughts?

So I wonder if we shouldn't actually replace cygwin32 with cygwin, and
not distinguish 32-bit from 64-bit. Neither windows-nt nor linux nor,
as far as I can see, any of the other systems, distinguish 32-bit from
64-bit.

Sigh, on reflection there's no way to win. Consider 3 ways forward:

1) We leave things as they are in src/s/cygwin*.h, edit all the files
that compare system-type to 'cygwin32' to include 'cygwin64';

2) We make the suggested change, i.e. set SYSTEM_TYPE to 'cygwin' in
src/s/cygwin*.h and _change_ all system-type comparisons to
'cygwin32' to use 'cygwin' instead;

3) We revert to my earliest patch, i.e. set SYSTEM_TYPE to 'cygwin32'
in src/s/cygwin*.h.

None of these are without pain:

(1) will cause obscure failures in existing user code which tests
system-type against 'cygwin32' if they run the 64-bit version;

(2) Same problem as (1), but worse -- happens if they run _either_
version;

(3) Doesn't break anything, but is misleading on the face of it.

(2) is clearly out, it seems to me -- we can't break the 32-bit
install for people who expect to update w/o pain.

I'm _slightly_ inclined towards (3), on the grounds that we still have
lots of '...win32...' names lying around which are actually perfectly
useful in 64-bit builds.

Thoughts?

ht

[Mats Lidell]

Post by Vin Shelton
I don't think breaking the 32-bit Windows native build in order to
build the 64-bit Cygwin build is progress.

I agree. But why should the native build need to be broken in order to
for the cygwin builds to work? Proper #ifdefs should handle the
different environments where needed. And the native build uses nmake
and not make so it is a separate build system with its pros and
cons.

So in the best of worlds we ought to build regularly (or ideally have
buildbot slaves for) the three (or four) windows environments in order
to keep things stable.

Yours

[Stephen J. Turnbull]

Post by Mats Lidell
I agree. But why should the native build need to be broken in order to
for the cygwin builds to work? Proper #ifdefs

May be prohibitively annoying to use because a lot of the *internal*
API stuff for Windows is automatically generated and needs to match up
with the system it's being build for, and other stuff is done by hand
in the makefile.inc or whatever it's called. Eventually we'll get
there, but *right now* things break.

If you want to work on the the "proper #ifdefs", that's another story,
but let's assume for now that Vin knows what's he's talking about and
Henry's quoting him accurately. If they want help, they'll explain.

@Vin

Speaking of help, there's a Microsoft guy over on python-dev who's
doing a lot of work dragging Python's native build out of the dark
ages (up to VS 2015 or whatever, which he says, and fairly
convincingly says, means there won't be another C API break in MSFT
compilers in our lifetimes). Name is Steve Dower, if you don't know
him I'd be happy to provide an address or an introduction.

[Mats Lidell]

Post by Stephen J. Turnbull
May be prohibitively annoying to use because a lot of the *internal*
API stuff for Windows is automatically generated and needs to match up
with the system it's being build for [...]

OK. I need to look into that then. I have some vague memory of some
perl stuff for generating things... could that be it?

Post by Stephen J. Turnbull
[...] and other stuff is done by hand in the makefile.inc or
whatever it's called. Eventually we'll get there, but *right now*
things break.

Well adjusting makefile.inc depending on what environment you build
for seems to me to be something we can live with. The APIs seems to be
more of a problem.

Post by Stephen J. Turnbull
If you want to work on the the "proper #ifdefs", that's another story,
but let's assume for now that Vin knows what's he's talking about and
Henry's quoting him accurately.

It never struck me they could be wrong ;-)

Yours

[Henry S. Thompson]

Post by Mats Lidell

Post by Stephen J. Turnbull
API stuff for Windows is automatically generated and needs to match up
with the system it's being build for [...]

OK. I need to look into that then. I have some vague memory of some
perl stuff for generating things... could that be it?

That's been done, at least wrt the _cygwin_ 64bit build. I believe you
already have my patches for that.

Wrt the native 64bit build, that's temporarily on hold while we try to
get the native 32bit build working with a 'modern' version of Visual
Studio/Visual C++. Help with that, also being discussed in this
thread, will of course be very welcome.

ht

[Henry S. Thompson]

Post by Henry S. Thompson

Post by Mats Lidell

Post by Stephen J. Turnbull
API stuff for Windows is automatically generated and needs to match up
with the system it's being build for [...]

OK. I need to look into that then. I have some vague memory of some
perl stuff for generating things... could that be it?

That's been done, at least wrt the _cygwin_ 64bit build. I believe you
already have my patches for that.

Slight correction -- that was folded into the trunk back in April, see
revs f66646c7bbe5 and 7ae4754e6105

ht

[Mats Lidell]

Post by Henry S. Thompson
Slight correction -- that was folded into the trunk back in April,
see revs f66646c7bbe5 and 7ae4754e6105

Yes, I thought so. That is good.

IMHO. It is good to keep the set of patches low. If anything you find
is a good change (moves us closer to the target without breaking
anything else) I think pushing it to trunk makes sense.

Yours

[Dr Rainer Woitok]

Henry and All,

Post by Henry S. Thompson
For 32-bit Cygwin, there is a working package.

Yes, I wanted to compile XEmacs under 32-bit Cygwin. And if you are re-
ferring me to the working Cygwin XEmacs package: no, that's not really
what I want (even though I'm currently using it). In the past Cygwin's
XEmacs package was some five years old, and even though it's now almost
current, I would definitely prefer compiling myself the version of my
own choice.

While my original post to this list has triggered a rather vivid dis-
cussion about compiling the 64-bit version, my original question referr-
ed to 32-bit Cygwin (though I forgot to explicitly mention that, sorry).

Therefore: could someone please be so kind to go back to my original
mail and tell me why I fail to compile XEmacs under 32-bit Cygwin?

Thanks
Rainer

[Henry S. Thompson]

...
Can't reproduce. That is, pulling from bitbucket, tip is revision
cb65bfaf7110, compiling with gcc, I get a working xemacs.

$ hg tip
Speed up XEmacs on X.
Avoid many calls to XQueryColor.
$

...
or better yet, follow the instructions for bug reporting at
https://cygwin.com/problems.html
and attach the cygcheck output as described therein.

See attachment below.

OK, my 32-bit install has fallen behind a bit, whereas yours is right
up-to-date. I'll need to refresh mine and retry the xemacs build,
probably not until tomorrow at this point.

ht

[Henry S. Thompson]

Post by Dr Rainer Woitok
Therefore: could someone please be so kind to go back to my original
mail and tell me why I fail to compile XEmacs under 32-bit Cygwin?

So, I brought my 32-bit environment up-to-date, and I still can't
reproduce. That is,

Post by Dr Rainer Woitok
with_x11=no ./configure '--with-pdump=yes' '--with-modules=no' '--with-mule=yes'
make
src/xemacs &

All works.

I see you're running on Vista -- maybe that's the problem, and I don't
have time now to try to find a Vista installation (I'm on 8.1 myself).
To (perhaps) confirm, please send me Installation, config.log,
config.status and src/config.h from your failed build.

ht

[Henry S. Thompson]

Next thing will be to verify that I have a working native environment.
Before summer it seems I installed VS2013. What do you think. Will
that suffice as a test environment or do I need to go for the 2015
version?

It would probably be better if you could install VS2015, it was pretty
painless (I unchecked _all_ the optional bits). There's clearly some
advantage in working in the same environment as we try to get things
working, as well as sharing with Python going forward. And VS2015
does seem to be what people will be loading if they start from
scratch. . .

Thanks,

ht

[Stephen J. Turnbull]

Post by Henry S. Thompson

Next thing will be to verify that I have a working native environment.
Before summer it seems I installed VS2013. What do you think. Will
that suffice as a test environment or do I need to go for the 2015
version?

As always, you're a volunteer. It could be argued that *somebody* is
likely to have (or be stuck on) that environment for some reason (eg,
other software that requires image libs built in that environment).
If so, it would be helpful to have it installed.

Post by Henry S. Thompson
It would probably be better if you could install VS2015, it was pretty
painless (I unchecked _all_ the optional bits). There's clearly some
advantage in working in the same environment as we try to get things
working, as well as sharing with Python going forward. And VS2015
does seem to be what people will be loading if they start from
scratch. . .

+1

Especially since the reports I have (already mentioned) are that
starting with VS2015 "native C APIs" in Windows will be fixed in stone
in some sense, and therefore it will be the preferred environment for
open source built on Windows.