Bug 695882 - ghostscript-9.16rc2 results some "implicit declaration of function" gcc warnings
Summary: ghostscript-9.16rc2 results some "implicit declaration of function" gcc warnings
Status: NOTIFIED FIXED
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Build Process (show other bugs)
Version: master
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-03-23 06:06 UTC by jsmeix
Modified: 2015-03-25 06:17 UTC (History)
0 users

See Also:
Customer:
Word Size: ---


Attachments
do_not_use_pread_and_pwrite_on_SLE11.diff (661 bytes, text/plain)
2015-03-23 06:20 UTC, jsmeix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jsmeix 2015-03-23 06:06:55 UTC
Currently ghostscript-9.16rc2 fails to build for SUSE SLE_11_SP3.

When I build
http://downloads.ghostscript.com/public/.release_candidate/ghostscript-9.16rc2.tar.gz
in the openSUSE build service for SLE_11_SP3 the gcc there outputs
--------------------------------------------------------------------------
./base/gp_unifs.c:187: warning:
 implicit declaration of function 'pread'
./base/gp_unifs.c:209: warning:
 implicit declaration of function 'pwrite'
./base/gp_psync.c:170: warning:
 implicit declaration of function 'pthread_mutexattr_settype'
--------------------------------------------------------------------------
If you like to have a look at the full build log, see
https://build.opensuse.org/package/live_build_log/Printing/ghostscript/SLE_11_SP3/x86_64

I think the issues in gp_unifs.c could be related to bug#695842

In the openSUSE build service special build check scripts are run
that check the compiler output for messages that are considered as
too bad to let the build finish and 'implicit declaration of function'
is one of those so that currently ghostscript-9.16rc2 fails to build
for SLE_11_SP3.

But for all newer openSUSE versions is builds successfully.

Only the relatively old SLE_11_SP3 uses gcc-4.3

All newer openSUSE versions use gcc-4.8
Comment 1 jsmeix 2015-03-23 06:20:02 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.
Comment 2 Chris Liddell (chrisl) 2015-03-23 06:43:46 UTC
(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.
Comment 3 jsmeix 2015-03-23 06:56:38 UTC
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.
Comment 4 Chris Liddell (chrisl) 2015-03-23 10:33:37 UTC
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.......
Comment 5 Chris Liddell (chrisl) 2015-03-24 08:22:48 UTC
Should be fixed with:

http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8bb53a7f
Comment 6 jsmeix 2015-03-25 06:17:52 UTC
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 ;-)