| Summary: | ghostscript-9.16rc2 results some "implicit declaration of function" gcc warnings | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | jsmeix |
| Component: | Build Process | Assignee: | Chris Liddell (chrisl) <chris.liddell> |
| Status: | NOTIFIED FIXED | ||
| Severity: | normal | ||
| Priority: | P4 | ||
| Version: | master | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | do_not_use_pread_and_pwrite_on_SLE11.diff | ||
|
Description
jsmeix
2015-03-23 06:06:55 UTC
Created attachment 11537 [details] do_not_use_pread_and_pwrite_on_SLE11.diff The attached do_not_use_pread_and_pwrite_on_SLE11.diff is my quick and dirty dumb "fix" to avoid the issue in gp_unifs.c I do not understand why for gcc-4.3 'pread' and 'pwrite' are implicitly declared in gp_unifs.c because it contains #include "unistd_.h" and that contains # define _XOPEN_SOURCE 500 # include <unistd.h> which shoud do "the right thing" - as far as I see...? The other issue (implicit 'pthread_mutexattr_settype' in gp_psync.c) is avoided by using the configure option --disable-threading. FYI: I am wondering if I may use --disable-threading in general to be more on the safe side because according to bug#695862 disabled multithreaded rendering is no big drawback and personally I prefer reliability over speed. Furthermore I wonder if perhaps disabled multithreaded rendering might be even required for some outpout devices because it seems there are also non-threadsafe devices as indicated by the --enable-threadsafe configure option but I don't know if and how --disable-threading and --enable-threadsafe are related to each other. (In reply to jsmeix from comment #1) > Created attachment 11537 [details] > do_not_use_pread_and_pwrite_on_SLE11.diff > > The attached do_not_use_pread_and_pwrite_on_SLE11.diff > is my quick and dirty dumb "fix" to avoid the issue > in gp_unifs.c > > I do not understand why for gcc-4.3 'pread' and 'pwrite' > are implicitly declared in gp_unifs.c because it contains > #include "unistd_.h" > and that contains > # define _XOPEN_SOURCE 500 > # include <unistd.h> > which shoud do "the right thing" - as far as I see...? AFAIK, it should work, so I think I would want to know why it doesn't, rather than just hacking the source...... It would certainly be good to know if there anything we should be doing to prevent the warning happening. > The other issue (implicit 'pthread_mutexattr_settype' in gp_psync.c) > is avoided by using the configure option --disable-threading. Again, that's really just a hack: pthread_mutexattr_settype() is (or should be) in pthread.h and is a function that has been around for *quite* some time - it's not a recent addition to pthreads. The declaration is there, and is available, on the Linux installs I have here. > FYI: > I am wondering if I may use --disable-threading in general > to be more on the safe side because according to bug#695862 > disabled multithreaded rendering is no big drawback and > personally I prefer reliability over speed. > Furthermore I wonder if perhaps disabled multithreaded rendering > might be even required for some outpout devices because it seems > there are also non-threadsafe devices as indicated by > the --enable-threadsafe configure option but I don't know > if and how --disable-threading and --enable-threadsafe > are related to each other. --disable-threading and --enable-threadsafe aren't really related to each other. --enable-threadsafe is about building a library which it threadsafe so callers can potentially create multiple Ghostscript instances in the same process (some devices use global variables hence cannot be included in such a build, and hence why it is not the default), whilst --disable-threading disables Ghostscript's (optional) internal use of threads to speed up rendering. FWIW, I don't believe there are stability problems with the mult-threaded rendering. The recent issue we had was exposed by a change in behaviour in the glibc pthreads implementation, and that's rather beyond our control. I only liked to report the issue early. Currently I do not yet understand why gcc-4.3 complains while it seems to "just work" everywhere else. Of course when I understand the root cause I do no longer need stuff like my "quick and dirty dumb 'fix'" but instead I would provide a nice description with a solution. OKay, so it looks like different systems might require different definitions to get access to these functions, which is really just a pain. We already set "_XOPEN_SOURCE 500" which I'm guessing is required on OS/X to get to pread/pwrite (based on the preferences of the engineer who did that work). Looks like we (also?) need "__USE_UNIX98" on Linux systems for pread/pwrite, and that will also pull in the declaration of pthread_mutexattr_settype. I can also tweak the configure script to drop the use of pread/pwrite but it's not so straight forward to do the same thing with pthread_mutexattr_settype so easily as the autoconf built-in test for declarations only operates on autoconf's default list of headers - which doesn't include pthread.h. My work-in-progress, if you are interested: http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=b39c9f55 For your purposes, hopefully, you should only need the changes in base/gp_psync.c and base/unistd_.h to resolve your warnings. More when I have it....... Should be fixed with: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8bb53a7f Awesome! I confirm that with the fix in comment#5 it now compiles even for gcc-4.3 . Many thanks for the fix! FWIW: On my SLE11-SP3 system "man pread" only reads: ------------------------------------------------------------------------- SYNOPSIS #define _XOPEN_SOURCE 500 #include <unistd.h> ------------------------------------------------------------------------- i.e. nothing about "__USE_UNIX98" - seems to be intentionally hidden so that only "real hard men" were able use that functionality ;-) |