Setting P1 since it breaks the development technology.

My Cygwin has been updated today.

I frequently use Cygwin and just tested against r

The invocation I use is:

./autogen.sh            (not bash autogen.sh)

perhaps the .bashrc doesn't set up the correct paths or environment variables.

The autoconf I have is: autoconf (GNU Autoconf) 2.61

and the gcc is: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

If you need more information/help on using Cygwin, please email me or
contact me on skype and I'll be glad to help you get past this. Cygwin is
a bit picky about setup options, but I have been doing this for a couple
of years on several different computers and seem to manage to get it to work,

I missed on pasting in the revision I tested.

I tested both 8016 and 8047 and autogen.sh works on both.

IIRC there was some issue in the past with not being able to create symbolic
links under windows. If this was the case again, copying might still be
necessary. copying src/configure.ac to configure will not work however. This is
like copying src/gs.c to obj/gs.exe. The proper sequence would be:

copy gs/src/configure.ac to gs/configure.ac
copy gs/src/Makefile.in to gs/Makefile.in
run autogen.sh

if autogen.sh cannot be made to execute, invoke 'autoconf' manually from the top
level gs directory, and then run ./configure && make as one would for a release.

Ray,

No, I don't want to skype or private email, because the resolution needs to be 
documented. Now I run Cygwin window and type "./autogen.sh" in it. Got same 
error as explained in Description. 

Please note it was working few weeks ago. I'm not sure what revision has 
regressed, let me know if you want me to determine that.

Ralph,

Are you sure to copy to "gs/configure.ac", "gs/Makefile.in" ? It 
wants "gs/configure", "gs/Makefile".

If you're still having problems, please include the entire output for
autogen.sh. I cannot tell what failed from the information you included.

Here is the full output, running in a fresh copy directory :


Administrator@MAY2003 ~
$ cd /cygdrive/f/AFPL/GS-HDU

Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
$ ./autogen.sh
Generating configuration files for ghostscript, please wait....
  creating links to configuration sources
  running autoconf
sh: autom4te.cache/output.1t: Permission denied
autom4te-2.61: /usr/bin/m4 failed with exit status: 1
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autogen.sh command line.
./autogen.sh: line 44: ./configure: No such file or directory

Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
$ cp src/configure.ac configure

Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
$ cp src/Makefile.in Makefile

Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
$ ./autogen.sh
Generating configuration files for ghostscript, please wait....
  creating links to configuration sources
  running autoconf
sh: autom4te.cache/output.1t: Permission denied
autom4te-2.61: /usr/bin/m4 failed with exit status: 1
I am going to run ./configure with no arguments - if you wish
to pass any to it, please specify them on the ./autogen.sh command line.
./configure: line 1: syntax error near unexpected token `('
./configure: line 1: `dnl  Copyright (C) 2001-2006 Artifex Software, Inc.'

Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
$

Thank you.

>   running autoconf
> sh: autom4te.cache/output.1t: Permission denied

This is the problem. You need to discover why this file could not be created or
accessed. Does the autom4te.cache directory exist? Does the file output.1t exist
within it? If so, can you read its contents? If not can you create it manually?

What happens if you run 'autoconf --verbose' manually in the top-level gs directory?

> Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
> $ cp src/configure.ac configure
>
> Administrator@MAY2003 /cygdrive/f/AFPL/GS-HDU
> $ cp src/Makefile.in Makefile

I have already explained that this cannot work. configure is generated from
configure.ac by the autoconf program. Makefile is generated from Makefile.in by
the configure script.

Note that you should not have "copied src/configure.ac to ./configure"

If anything you need to: cp src/configure.ac .
(creating a configure.ac using cp instead of ln)

I am running Cygwin on XP Pro and symbolic links work fine.

This can be tested by:

ln -s src/gs.c .
ls -l gs.c
rm gs.c

the results should be:

$ ln -s src/gs.c .
$ ls -l gs.c
1 lrwxrwxrwx 1 ray None 1 Jun 13 13:03 gs.c -> src/gs.c
$ rm gs.c

---

I noticed Ralph's comment about "autom4te.cache/"

You can try:  rm -fr autom4te.cache

to get rid of it.

Well, autom4te.cache looks the real problem. It resides in NTFS file system, 
and it is read-only for creator and owner. Others have no access. I can't 
delete it. I guess the bottom of the problem is that Windows domain server was 
re-installed (a month ago on another machine !) and then domain users were re-
created in there. 

I could get rid of it with (1) renaming the father directory, (2) creating a 
new directory with the old name, (3) copied everything except autom4te.cache 
from the renamed directory to the new directory. Well it still resides in the 
renamed directory, and I think I need to format HDD to get rid of it completely.

./autogen.sh now runs, maybe I'll add something when it completes.

Thanks, Ralph. 

Now autoconf completed, but there is a compile problem :

In file included from /usr/include/sys/signal.h:107,
                 from /usr/include/signal.h:5,
                 from /usr/include/time.h:140,
                 from /usr/include/sys/stat.h:9,
                 from ./src/stat_.h:27,
                 from ./src/gxiodev.h:21,
                 from ./src/stream.h:22,
                 from ./src/zfile.c:36:
/usr/include/cygwin/signal.h:54: error: parse error before '->' token
/usr/include/cygwin/signal.h:58: error: parse error before '}' token
make[1]: *** [obj/../debugobj/zfile.o] Error 1


The problematic line is :

  unsigned long esp;

I guess it conflicts with gs macro 'esp'.

I will change the gs macro to something other than 'esp'

Created attachment 3102 [details]
patch

Include the system headers first to avoid name conflict between Cygwin
headers and a Ghostscript macro. This works because (1) we don't use
the affected structure, (2) system header files are protected from double
inclusion.

The problem can was reproduced in v. CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31

but not in v. CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02

The patched version compiles on Cygwin, GNU+Linux, MSVC 6 & 7 and causes no
differences in regression testing.

The patch is committed as a rev. 8094.

*** Bug 689357 has been marked as a duplicate of this bug. ***