Bug 344721 - gocr-devel should be built as well
gocr-devel should be built as well
Product: Fedora
Classification: Fedora
Component: gocr (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Smetana
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2007-10-21 16:56 EDT by Matěj Cepl
Modified: 2008-09-04 07:33 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-09-04 07:33:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matěj Cepl 2007-10-21 16:56:13 EDT
Description of problem:
It is possible to build packages using gocr and there is /usr/include/gocr.h for
that. Unfortunately, you have removed it together with .a file, and so there are
programs (not in Fedora -- my problem was ogmrip from ogmrip.sf.net) which are
not compilable under Fedora.

There are packages of gocr available at http://mcepl.fedorapeople.org/rpms/
which IMHO fix this problem.
Comment 1 Patrice Dumas 2007-10-21 17:07:28 EDT
I think this is a good idea, too. Do you want that I do it?
Comment 2 Matěj Cepl 2007-10-21 17:59:48 EDT
Whom do you ask? Me? If so (and I doubt it ;-)), then just go ahead -- that's
the reason why I filed this bug.
Comment 3 Patrice Dumas 2007-10-21 18:09:30 EDT
No, I was asking Orion ;-), he his the primary maintainer...
Comment 4 Orion Poplawski 2007-10-21 23:19:50 EDT
Well, the mcepl package adds the .h for but not the library, which I have a hard
time imagining to be useful.  Fedora has a strong bias against shipping static
libraries.  I would rather work with upstream to ship a shared library instead.
Comment 5 Patrice Dumas 2007-10-22 03:11:58 EDT
In my opinion there is no problem shipping a static library 
when upstream doesn't provide a shared library. That doesn't preclude
working with upstream at the same time. It is problematic because
unneeded rebuild may be needed when the library is updated, but 
otherwise it isn't that a big deal.
Comment 6 Matěj Cepl 2007-10-22 04:53:30 EDT
This is probably the relevant information on the topic.
Comment 7 Tomas Smetana 2007-11-08 06:58:01 EST
I've sent a patch upstream and made these testing packages that contain DSO
instead of a static library.  You may try:
Comment 8 Tomas Smetana 2008-01-11 03:09:25 EST
Does anybody actually care of this one?  I'm going to close this one as WONTFIX
if not.  The patch was reported upstream (no response) so maybe one day they
decide to incorporate it.
Comment 9 Patrice Dumas 2008-01-11 03:45:28 EST
In my opinion we should ship the static library if somebody needs it
and otherwise we can wait for upstream inclusion of DSO build.
Comment 10 Tomas Smetana 2008-01-11 04:27:09 EST
Shouldn't we rather keep the patch then and ship the DSO?  We maintain patches
in other packages to keep them in line with our policies.  And this one is quite
Comment 11 Patrice Dumas 2008-01-11 05:36:31 EST
It is not simple at all, since it involves setting a soname. I have
put an explanation about why I find it bad to add shared lib in fedora
without upstream consultation, the second point on:

Comment 12 Matěj Cepl 2008-01-11 12:15:28 EST
I would vote for keeping our own patch. The patch is actually pretty simple, we
just don't delete upstream .h file, so there is no reason to believe that this
will evolve substantially different.
Comment 13 Tomas Smetana 2008-01-14 04:54:52 EST
(In reply to comment #12)
> I would vote for keeping our own patch. The patch is actually pretty simple, we
> just don't delete upstream .h file, so there is no reason to believe that this
> will evolve substantially different.

We were talking about my patch that adds the DSO.  Shipping a header file
without a library is useless.  After reading Patrice's arguments I agree to
include the static library in the package.
Comment 14 Tomas Smetana 2008-01-14 05:40:50 EST
I've updated the packages at

If there will be no objections I'll build them in rawhide.
Comment 15 Patrice Dumas 2008-06-10 05:28:06 EDT
I have checked gocr.h, and found that it refers to other gocr 
files, pnm.h, unicode.h and list.h and also uses autoconf
conditionals. pnm.h includes config.h.

I suggest the following:
* remove the autoconf conditionals from gocr.h (setting them to what
  they should be, that is HAVE_GETTIMEOFDAY should be defined)
* remove the  g_debug symbol definition from list.h
* remove the config.h include in pnm.h
* rename pnm.h gocr_pnm.h, list.h gocr_list.h and unicode.h gocr_unicode.h
  and change the corresponding includes in gocr.h

I don't know exactly how these changes could be done. Maybe the
best would be a patch applied in the $RPM_BUILD_ROOT directory.
Comment 16 Patrice Dumas 2008-06-10 05:52:47 EDT
Also it seems to me that pgm2asc.h could be shipped, given that
it has the same name than the library I guess that it is related.
It is also an include file used in the software I am looking at
(swftools) which uses gocr.

In that case the following should be patched out:

#ifndef HAVE_WCHAR_H
const wchar_t *wcschr (const wchar_t *wcs, wchar_t wc);
const wchar_t *wcscpy (wchar_t *dest, const wchar_t *src);
size_t wcslen (const wchar_t *s);
wchar_t * wcsdup (const wchar_t *WS);   /* its a gnu extension */
Comment 17 Tomas Smetana 2008-06-10 06:13:53 EDT
...and nobody noticed this for six months.

Looking at the required changes I would really like to see them implemented
upstream first.
Comment 18 Tomas Smetana 2008-09-04 07:33:55 EDT
I've removed the useless devel package again.  Closing with WONTFIX -- the required changes would be too invasive.

Note You need to log in before you can comment on or make changes to this bug.