Re: [pdf-devel] "Hello" and questions

[jemarch]

   > ../../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  <address@hidden>
                  http://www.jemarch.net
GNU Project       http://www.gnu.org