> ../../src/base/pdf-fsys-disk.c -DDLL_EXPORT -DPIC -o .libs/pdf-fsys-disk.o > ../../src/base/pdf-fsys-disk.c: In function > '__pdf_fsys_disk_get_status_from_errno': > ../../src/base/pdf-fsys-disk.c:1442: error: 'EOVERFLOW' undeclared > (first use in this function) > ../../src/base/pdf-fsys-disk.c:1442: error: (Each undeclared identifier > is reported only once > ../../src/base/pdf-fsys-disk.c:1442: error: for each function it appears > in.) > ../../src/base/pdf-fsys-disk.c:1451: error: 'ETXTBSY' undeclared (first > use in this function) > make[2]: *** [pdf-fsys-disk.lo] Error 1 > make[2]: Leaving directory `/home/code/lignupdf/w32/src' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/code/lignupdf/w32/src' > make: *** [all-recursive] Error 1 > [...] > > Which I "hotfixed" commenting lines 1442 and 1451 of > src/base/pdf-fsys-disk.c just to go on.
Instead of commenting them, I would include them between host-based macros. #ifndef PDF_HOST_WIN32 whatever here #endif Well, that is only if W32 is the only architecture without those errno errors. There should be a more clean way of doing it, I guess. That modification should not be required. The lib/errno.h header file provided by gnulib is defining both EOVERFLOW and ETXTBSY when they are missing. It works for me using mingw32 4.2.1. > [SEVERAL MORE LIBGCRYPT UNDEFINED REFERENCES] > > collect2: ld returned 1 exit status > make[2]: *** [libgnupdf.la <http://libgnupdf.la>] Error 1 > make[2]: Leaving directory `/home/code/lignupdf/w32/src' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/home/code/lignupdf/w32/src' > make: *** [all-recursive] Error 1 > > Which I "hotfixed" running > > make LDFLAGS=-lgcrypt > > And building finished successfully, so to speak. Humm.. why is this happening? There were a problem in the detection of libgpg-error and libgcrypt when compiling for mingw32. It is now fixed in the trunk. > > So, are these issues known or is there something wrong with my environment? > Is something else required to build the tests correctly? > How was libgnupdf built in the report citated in FS#85? Yes, the --enable-nocheck option that I told before. You need it to compile the unit tests. Then you can follow the steps given in the email referred in FS#85 to try to reproduce it. The compilation of the unit tests fails when compiling torture/unit/base/stm/pdf-stm-write.c, due to the usage of check fixtures introduced by a recent patch. Currently nocheck is not supporting fixtures. I think that at this point it would be a good idea to check if the latest version of check.sf.net is supporting mingw32 well enough to replace nocheck. The alternative would be to implement the fixture capabilities in nocheck, but we don't want to write a full replacement of check :) -- Jose E. Marchesi <[email protected]> http://www.jemarch.net GNU Project http://www.gnu.org
