Red Hat Bugzilla – Bug 344721
gocr-devel should be built as well
Last modified: 2008-09-04 07:33:55 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.
I think this is a good idea, too. Do you want that I do it?
Whom do you ask? Me? If so (and I doubt it ;-)), then just go ahead -- that's
the reason why I filed this bug.
No, I was asking Orion ;-), he his the primary maintainer...
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.
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.
This is probably the relevant information on the topic.
I've sent a patch upstream and made these testing packages that contain DSO
instead of a static library. You may try:
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.
In my opinion we should ship the static library if somebody needs it
and otherwise we can wait for upstream inclusion of DSO build.
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
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:
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.
(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.
I've updated the packages at
If there will be no objections I'll build them in rawhide.
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.
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:
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 */
...and nobody noticed this for six months.
Looking at the required changes I would really like to see them implemented
I've removed the useless devel package again. Closing with WONTFIX -- the required changes would be too invasive.