emacs-build
emacs-build copied to clipboard
error: expected identifier before numeric constant
HI
My query is partly relevant to the issue here: https://github.com/juanjosegarciaripoll/emacs-build/issues/5.
The title pretty much says it all. It's an error message I get when your build script tries to compile w32image.c
in the Emacs src
directory because of the include of w32common.h
in the same directory. It's a line in an enum
declaration without an explicit initializer, i.e., it defaults to 0. The compiler complains and the build fails right at that step. FWIW, I'm building fejfighter/emacs
and it's nearly there. I'll only go thru the few changes I made in minimal detail because ultmimately in the end they didn't solve the problem. fejfighter/emacs
is a pgtk+nativecomp build. So I needed to go into emacs-build.sh
(I know not what you had in mind at all) and change the repo to point to that and also change the branch to pgtk-nativecomp
. That doesn't seem to cause any problems at all. I, of coursse, had to use a customized cmd
of two lines to get it to do the right thing but the details aren't important. Ultimately (I think) I tracked it down to the gcc
warning flag -Wno-missing-field-initializers
so to deal with that I had to go into configure.ac
and comment the relevant line out. I was sure that would take care of it. It hasn't. I might mention that I successfully built fejfighter/emacs
on Ubuntu 21.04 despite the wellknown relevant bug in Ubuntu.
There appear to be a bunch of similar posts to Stack Overflow etc. all to do wth various problems related to Wndows installs of lots of different software (including notably SciPy) based on msys64
and mingw64
in the msys2
distribution. It would be hard to establish without providing lots of urls to check but the most intelligent suggestion Iv'e come across is that it has to do with new style headers than the (older) version of gcc
can handle. Since the Emacs version is 28.0.50 IIRC that seems very possible.
So in conclusion two questions:
- Do you have any insight into this about a possible workaround I might try if what I've outlined is indeed the problem without having to find alternative header files (which I always find to be a maintenance nightmare at least)? In particular, can I adjust your script to get a newer version of
gcc
(if that's indeed ultimately the problem)? - What in general is the correct overall strategy for "adjusting" your script for use cases you didn't originally envisage?
FWIW, I think your script is awesome!
Thanks very much in advance for any light at all you can shed on my two questions
Best regards Mike
FWIW this is the intelligent suggestion I mentioned:
Sorry I get there in the end ... here's the C header file:
/* Common functions for Microsoft Windows builds of Emacs
Copyright (C) 2012-2020 Free Software Foundation, Inc.
This file is part of GNU Emacs.
GNU Emacs is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or (at
your option) any later version.
GNU Emacs is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
*/
#ifndef W32COMMON_H
#define W32COMMON_H
#include <windows.h>
#define ROUND_UP(p, align) (((DWORD_PTR)(p) + (align)-1) & ~((DWORD_PTR)(align)-1))
#define ROUND_DOWN(p, align) ((DWORD_PTR)(p) & ~((DWORD_PTR)(align)-1))
#define get_page_size() sysinfo_cache.dwPageSize
#define get_allocation_unit() sysinfo_cache.dwAllocationGranularity
#define get_processor_type() sysinfo_cache.dwProcessorType
#define get_w32_major_version() w32_major_version
#define get_w32_minor_version() w32_minor_version
extern SYSTEM_INFO sysinfo_cache;
extern OSVERSIONINFO osinfo_cache;
extern DWORD_PTR syspage_mask;
extern int w32_major_version;
extern int w32_minor_version;
extern int w32_build_number;
enum {
OS_9X = 1,
OS_NT = 0
};
extern int os_subtype;
/* Cache system info, e.g., the NT page size. */
extern void cache_system_info (void);
typedef void (* VOIDFNPTR) (void);
/* Load a function address from a DLL. Cast the result via VOIDFNPTR
to pacify -Wcast-function-type in GCC 8.1. The return value must
be cast to the correct function pointer type. */
INLINE VOIDFNPTR get_proc_addr (HINSTANCE, LPCSTR);
INLINE VOIDFNPTR
get_proc_addr (HINSTANCE handle, LPCSTR fname)
{
return (VOIDFNPTR) GetProcAddress (handle, fname);
}
/* Define a function that will be loaded from a DLL. The variable
arguments should contain the argument list for the function, and
optionally be followed by function attributes. For example:
DEF_DLL_FN (void, png_longjmp, (png_structp, int) PNG_NORETURN);
*/
#define DEF_DLL_FN(type, func, ...) \
typedef type (CDECL *W32_PFN_##func) __VA_ARGS__; \
static W32_PFN_##func fn_##func
/* Load a function from the DLL. */
#define LOAD_DLL_FN(lib, func) \
do \
{ \
fn_##func = (W32_PFN_##func) get_proc_addr (lib, #func); \
if (!fn_##func) \
return false; \
} \
while (false)
/* Load a function from the DLL, and don't fail if it does not exist. */
#define LOAD_DLL_FN_OPT(lib, func) \
do \
{ \
fn_##func = (W32_PFN_##func) get_proc_addr (lib, #func); \
} \
while (false)
#ifdef HAVE_HARFBUZZ
extern bool hbfont_init_w32_funcs (HMODULE);
#endif
The relevant line is line 45. What I've attached is my changed version. In the original the `= 0` was absent.
The relevant line is the one with OS_NT = 0
on line 45 in the enum
. As I said the original was missing = 0
. It's not a greaat error message. The way I would read it is that gcc
thinks the O
at the beginning of the line was a 0
!