emacs-build icon indicating copy to clipboard operation
emacs-build copied to clipboard

error: expected identifier before numeric constant

Open mikereape opened this issue 3 years ago • 2 comments

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:

  1. 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)?
  2. 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

mikereape avatar Aug 04 '21 02:08 mikereape

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!

mikereape avatar Aug 04 '21 02:08 mikereape