Created attachment 6491 [details] the full autogen.sh configure make log (I did build r11229 on the same machine with gcc two months ago about two weeks before the ICC merge, so none of these problems are unfixable, but quite a few are non-trivial) This is probably an example of a legacy unix platform which doesn't have most of the GNU tools or the GNU variant of typical unix tools. There are many errors and warnings from both the tools and C compiler, here is a summary list but I'll attach the log itelf (the full autogen.sh ; configure ; make , since some of the errors are in the configure stage). -----------things during autogen.sh/configure - there is a strange warning at the beginning: configure: WARNING: you should use --build, --host, --target - sed is not GNU sed, and doesn't even support the probing from configure tests - jbig2dec (this seems to apply to HP-UX also, a few weeks ago, and was fixed) configure: WARNING: JBIG2 support requires stdint types which do not seem to be available. - about 140 lines of "./configure: !: not found" was outputted in the middle of running configure . ---------- non-GNU make Warning: PSRESDIR changed after being used ----------- compiler cc: Warning: ./base/gsciemap.c, line 797: In this statement, the shift count "-2" is negative or is greater than or equal to the promoted size of the operand cc: Warning: ./base/gdevbbox.c, line 1197: The scalar variable "cdev" is fetched but not initialized cc: Warning: lcms/include/icc34.h, line 321: In this declaration, the enumeration constant "icMaxEnumTag" is out of range INT_MIN to INT_MAX cc: Warning: ./base/mkromfs.c, line 989: In this statement, this argument to printf contains a bad conversion specification "%r" that will cause unpredictable behavior. (ba dconvspec) --- dependency (configure or make - for some reason libps3 is roped in:) ld: Unresolved: gs_lips3_device *** Exit 1
Created attachment 6492 [details] trimmed log removing type-cast warnings. result of: grep -i warning 6491 | grep -v 'referenced type of the pointer value' Here are the more interesting/alarming ones: cc: Warning: ./base/gsciemap.c, line 797: In this statement, the shift count "-2" is negative or is greater than or equal to the ... cc: Warning: ./base/gdevbbox.c, line 1197: The scalar variable "cdev" is fetched but not initialized. cc: Warning: lcms/include/icc34.h, line 321: In this declaration, the enumeration constant "icMaxEnumTag" is out of range (and a lot of similar ones with lcms) cc: Info: lcms/src/cmssamp.c, line 455: The pragma "warning" is unrecognized. (unknownpragma) cc: Warning: ./base/mkromfs.c, line 989: In this statement, this argument to printf contains a bad conversion specification "%r" that will cause unpredictable behavior. (ba dconvspec) The actual part in first one is Igor's so I don't know where that should go, but Michael seems to have been working on that file lately. The 2nd and the last one goes to Ray, and the lcms ones goes to Michael, I guess.
(In reply to comment #0) > ---------- non-GNU make > Warning: PSRESDIR changed after being used Apparently I have already seen it with this one with gcc build and decide to leave this alone: http://bugs.ghostscript.com/show_bug.cgi?id=691299#c2
The mkromfs one is easy. I'm surprised that it hasn't shown up. Some of the places we are trying to print '%rom%' use "%%rom%%" but there are two places that don't. I'll fix this soon.
Created attachment 6503 [details] patch for the various issues brief description of the changes are: ------------- configure.ac : hide unsighty sed error message when it does not support --version gdevbbox: distinguish the two uses of cdev - one from icc merge, one from very old lpd code autogen.sh : the extra quote isn't needed and confuses some shell into running ./configure "" resulting in the WARNING: you should use --build, --host, --target configure.ac, jbig2dec: on Tru64 stdint.h does not exist but the jbig2 required type is in inttypes.h configure.ac: == is a bash extension - see bash manpage recommending = for posix compliance romfs: % in printf needs to be %% configure.ac: remove duplicate AC_PATH_PROG pkg-config - this causes "./configure: !: not found" messages on some platforms --------- I'll mail Michael separately about the gdevbbox fix since it looks like a possible serious bug and should go in ASAP; the romfs bits are as Ray said, a genuine bug that gcc doesn't complain about ; most of the others are about /bin/sh being not GNU bash and have no effect on linux/Mac OS X or where GNU bash is used (and sed not being GNU sed). The configure.ac part of the stdint.h/inittype.h change is probably slightly risky on older non-Linux unix systems where stdint.h doesn't exist.
Hin-Tak: The part for gdevbbox looks good. I should have noticed that earlier. Thanks.
Created attachment 6568 [details] The gdevbbox part of the 'various issues' patch The gdevbox part of the "various issues" patch, to distinguish the two uses of cdev - one from icc merge, one from very old lpd code. This looks like a potentially important issue so should be committed soon, first and separately. This is #17; the other parts of the "various issues" patch (attachment 6503 [details]) were broken down as #09 to #16 in http://ghostscript.com/~hintak/patchset/gs-patches/ (it happened the other way round - I made a small patch for each tiny issue before combining them and posted it as one).
I have tried to commit the patches. Patches #9 - #13 I have committed now and they do not break anything. With patch #14 applied the compilation on the cluster (Linux) breaks. So one cannot simply remove the quotes. Linux needs them and DEC seems to need them removed. Do to the broken test of patch #14 my uploads of patch #15 to #17 got also rolled back and so they are not tested now.
I have committed patch #16 now and the cluster regression is checking it. According to local testing (Ubuntu Maverick) it is OK. Patch #15 works also locally on my Maverick box.
Also patch #17 compiles and works on my local box and answers of the "bbox" device are still correct.
(In reply to comment #7) > Linux needs > them and DEC seems to need them removed. Do to the broken test of patch #14 my > uploads of patch #15 to #17 got also rolled back and so they are not tested > now. It is more Marcos's trying put put cflags into part of the compiler command - if you do ./autogen.sh option1="A B" option2="C D" and inside ./autogen.sh it says runthis "$@" depends on what shell you have, it could be this getting passed to the sub-shell as: runthis "option1="A B" option2="C D"" or this: runthis "option1=A B option2=C D" or this: runthis option1=A B option2=C D And the sub-shell can strip quotes as part of its input or not; so the actual arguments being passed to runthis could be: runthis/option1=A/B option2=C/D (3 arguments) runthis/option1=A B option2=C D (1 argument) runthis/option1=A/B/option2=C/D (4 arguments) depending on how many level of quotes are stripped and at what stage. Relying on quotes to protect arguments with spaces just isn't a good idea; and CFLAGS should be set in CFLAGS rather than in CC in any case. In fact I think doing: option1="A B" option2="C D" ./autogen.sh might be prefered, as they get passed spaces in those variables intact as environment variables rather than shell varibles. (but that syntax is bash/sh-ism, and would break when the user's shell is csh, for example).
Committed #16 and it passed the cluster regressions. #17 is also committed, waiting for the cluster regressions.
So everything but #14 is committed. Hin-Tak, now it is your decision to close the bug as fixed or to leave it open until the problem of #14 is fixed. I suggest to open one separate bug for each patch in such a case.
The remaining problem is the quotes in autogen.sh, but we shouldn't be calling configure from autogen.sh. Traditionally autogen.sh is run by developers after checking the code out of the repository, the autogen.sh script then generates a configure script, and the user runs configure. The configure script should be distributed with the release, users shouldn't have to run autogen.sh at all. We have to figure out the history of why things got this way (autogen.sh running configure). If nobody knows I'll probably contact Ralph.
(In reply to comment #13) > The remaining problem is the quotes in autogen.sh, but we shouldn't be calling > configure from autogen.sh. Traditionally autogen.sh is run by developers after > checking the code out of the repository, the autogen.sh script then generates a > configure script, and the user runs configure. The configure script should be > distributed with the release, users shouldn't have to run autogen.sh at all. > We have to figure out the history of why things got this way (autogen.sh > running configure). If nobody knows I'll probably contact Ralph. That line and the quote was there in the very first check-in (r1982) of autogen.sh - the quotes were probably there because it was not a problem with Mac OS X or Linux - both of Mac OS X and Linux use GNU bash as /bin/sh . To run ./configure right away is probably a matter of convenience. It is a matter of nobody ever tried on non GNU-bash, and diagnose the issue. I agree autogen.sh is not needed for releases, so this is a minor issue (as is this whole bug report which concerns a niche platform) - however, the inability to run it correctly (or seeing some strange errors when running) would be a deterrant for 3rd-party to contribute, particularly for issues on platforms which Artifex staff does not have access of, between releases.
autogen runs autoconf, then runs configure. This is what I recall from discussions with Ralph. Presumably, this is to make sure that the configure script is correct for a particular platform (the autoconf shouldn't generate a bad configure script). The 'configure' script distributed with ghostscript was primarily intended to be a convenience for linux users where the configure script can be trusted to run, but the intent was that if running './configure' doesn't work, you may need to run autoconf to generate a configure for your system. Just because linux users are used to getting a configure script they can run without autoconf, does not mean that we will support the configure script itself (we just distribute one that we generate using autoconf on one of our systems). All changes intended to affect the configure script generation should be made to configure.ac
Do we (Artifex) have access to a Tru64 (or equivalent) machine to test with? We could make the autogen.sh script a bit more intelligent in when it does the parameter quoting.
(In reply to comment #16) > Do we (Artifex) have access to a Tru64 (or equivalent) machine to test with? We > could make the autogen.sh script a bit more intelligent in when it does the > parameter quoting. I thought you have one of the solaris'es? Marcos' has an HP-UX AllianceOne account - I took the quick way out (transferring a cooked "configure" the last time, since there was no autoconf, etc on that box), and Alex has some strange boxes as well. Try find anything with a non GNU-bash /bin/sh (i.e. not linux nor Mac OS X).
in gs/toolbin/localcluster/run.pl around line 595 in two lines: The rather ugly construct: \"CC=gcc -m$wordSize\" can (should?) be replaced by CFLAGS=-m$wordSize LDFLAGS=-m$wordSize without those ugly backslash'ed quotes .
Am I right in thinking that everything other than the autogen.sh quoting thing, and the run.pl issue are resolved? If so, then I am inclined to close this: the autogen.sh issue has a trivial workaround (run autogen.sh, then run configure with the options you required) - plus there is no need to run autogen.sh when building from a *release* archive. And run.pl is really (currently, at least) targetted at Linux, where it clearly does what it needs to do, and is not really for "general consumption".