Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: PATCH zsh-3.1.5-pws-7: cygwin make fixes



I wrote:
> Bart wrote:
> > I haven't examined the patch in detail to check this, but did you make
> > sure that the compilation of this program is performed in such a way that
> > it executes correctly on the current hardware even when cross-compiling
> > for another architecture?
> 
> The trouble is mksignames actually has to run on the target
> architecture to generate the appropriate signal names.  I don't know
> if there's any way of doing that at all with autoconf.  Any more
> ideas?  We could maybe make it conditional on not cross-compiling,
> since it does solve the #include problem fairly neatly.

As configure.in contains AC_TRY_RUN statements, it looks to me
unlikely that the zsh build system supports cross-compilation anyway
--- this is specifically warned about in the autoconf manual ---
in which case there's no objection to Matt's patch.  Does anyone know
for a fact that zsh has ever been successfully cross-compiled?

FYI, the tests that currently have to be run, rather than just
compiled, are the following.  All but the first five are to do with
dynamically linked libraries.

- signed to unsigned casting
- if tgetent accepts NULL
- if rlim_t is quad_t
- if rlim_t is unsigned
- if named FIFOs work

- for ELF binaries
- if dlsym() needs a leading underscore
- if static/shared linking is broken
- if name clashes in shared objects are ok
- whether cross-library links are ok
- for working RTLD_GLOBAL
- if libraries can find symbols in exec
- whether executables can be stripped
- if dynamically loaded libs can be stripped

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy



Messages sorted by: Reverse Date, Date, Thread, Author