Solaris has O_LARGEFILE but not fdopen64, which is a linuxism. gcc -I/usr/openwin/include -DSTDINT_TYPES_DEFINED=1 `cat ./obj/cc.tr` -DHAVE_MKSTEMP -O2 -Wall -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -fno-builtin -fno-common -DGX_COLOR_INDEX_TYPE='unsigned long long' -I./obj -I./src -o ./obj/gpmisc.o -c ./src/gpmisc.c ./src/gpmisc.c: In function `gp_fopentemp_generic': ./src/gpmisc.c:97: error: `fdopen64' undeclared (first use in this function) ./src/gpmisc.c:97: error: (Each undeclared identifier is reported only once ./src/gpmisc.c:97: error: for each function it appears in.) ./src/gpmisc.c:97: warning: cast discards qualifiers from pointer target type gmake[2]: *** [obj/gpmisc.o] Error 1 gmake[2]: Leaving directory `/home/majid/src/ghostscript-8.56' gmake[1]: *** [ghostscript-8.56/bin/gs] Error 2 gmake[1]: Leaving directory `/home/majid/src' gmake: *** [gs] Error 2
Created attachment 2886 [details] Full build log for gs 8.56 on Solaris 10/x86
Reassigning bug to Igor since he did this implementation (64-bit clist file IO)
Dear Fazal Majid, Could you please submit a patch for this ? We don't have Solaris to debug it.
We used to be able to use the sourceforge.net compilefarm for such things, but it was recently taken down. Howe, Solaris x86 is now a free download, you can install it under vmware for local testing. http://www.sun.com/software/solaris/get.jsp http://www.vmware.com/products/ws/
Well, fdopen64 seems to be a non-standard extension of the GNU libc, so GS should not assume it is present just because large file support is enabled. I managed to build 8.56 on Solaris by passing -Dfdopen64=fdopen to gcc.
Passing to Ralph who handles build and documentation issues.
64-bit support is not perfect on Linux either. There are GCC warnings: ./src/gp_unifs.c:93: warning: implicit declaration of function "mkstemp64" ./src/gp_unifs.c:485: warning: implicit declaration of function "fopen64" ./src/gp_unifs.c:485: warning: return makes pointer from integer without a cast ./src/gp_unifs.c:503: warning: implicit declaration of function "ftello64" ./src/gp_unifs.c:516: warning: implicit declaration of function "fseeko64" Normally, _LARGEFILE64_SOURCE flag is set by the program, and the testing for this flag in gp_unifs.c is reversed. The varning about a "pointer from integer" is serious in LP64 model.
Created attachment 2894 [details] tgz for 3 relevant man pages on solaris 11 3 man pages on solaris 11 which describes the programming issues to do with fopen64
I have access to a solaris 11(?it reports itself as 5.11) x86 box with gcc 3.4.6 at work if some testing etc is needed.
Note that my original bug report was about the build breaking due to the absence of fdopen64, not fopen64 (which is indeed open on Solaris).
sorry, wasn't reading carefully about fdopen64/fopen64... but I believe those man pages I attached are still somewhat useful...
FYI - I also received this error on AIX 5.3. I modified gpmisc.c and changed fdopen64 to fopen64 and that seemed to fix the problem.
Created attachment 3082 [details] fdopen64/fdopen patch This patch should fix the problem on systems with largefiles, but no fdopen64. It may or may not want to be the way you go. I have only verified it on Solaris
Norm, Thanks for the patch. Just to make sure I understand properly: on Solaris, O_LARGEFILE is defined, and open() gets called with O_LARGEFILE in the flags. The result is a file handle with an off64_t, and then calling vanilla fdopen() propogates that to the FILE*. That is, with your patch, we're still able to use >2 GB of file storage?
Hold on to the patch for the moment. The build works, and ghostscript appears to work, but I haven't tested with a largefile yet.
I have verified that it works with large files on Solaris, but requires that you build with -D_LARGEFILE_SOURCE to do so. I will look into making this automatically detected via configure and submit a new patch.
Created attachment 3087 [details] updated largefile/fdopen/fdopen64 build patch This patch updates configure.ac, Makefile.in, and gpmisc.c. The configure changes allow the use of getconf(1) to determine which CFLAGS are required to enable largefiles support during compilation. The changes also combine the results of this with the results of the fopen64 and fdopen64 function checks to create a single autconf substitution for Makefile generation. The new substitution (LARGEFILE_CFLAGS) should include any necessary CFLAGS additions for largefiles support. I have built and run on Solaris Nevada build 66 on x86 hardware using files of varying size up to 2.6GB I didn't bother to try files any larger, presumably, they work as well.
This is still an issue with ghostscript 8.60, I'm building on AIX 5.3 64bit. fdopen64 is a non standard thing that's unneccesary since fdopen simply opens the file in whatever mode it's in. If it was opened with O_LARGEFILE then the end result will be largefile capable. The correct fix for this is to simply rip out the fdopen64 sillyness.
Created attachment 3343 [details] Remove fdopen64 sillyness. Patch to remove fdopen64 usage altogether - it's simply not needed.
fdopen64() is removed in the rev. 8229. I don't know about a single platform where it's needed. Google knows only 250 pages that mention fdopen64() vs. 38400 pages for fopen64(). Most of the 250 pages are about this bug or similar bugs in other software.