starred/ccextractor
1
0
Fork 0
mirror of https://github.com/CCExtractor/ccextractor.git synced 2026-02-03 21:23:48 +00:00
Code Issues 1.5k Packages Projects Releases 20 Wiki Activity

[BUG] Autogen Compilation terminates at make #567

New Issue
Closed
opened 2026-01-29 16:47:55 +00:00 by claunia · 7 comments
claunia commented 2026-01-29 16:47:55 +00:00
Owner
Copy Link

Originally created by @vishwesh-D-kumar on GitHub (Mar 3, 2020).

CCExtractor version: 0.88

In raising this issue, I confirm the following:

  • I have read and understood the contributors guide.
  • I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present.
  • I have checked that the issue I'm posting isn't already reported.
  • I have checked that the issue I'm porting isn't already solved and no duplicates exist in closed issues and in opened issues
  • I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
  • I have used the latest available version of CCExtractor to verify this issue exists.
  • I have ticked all the boxes in this section and to prove it I'm deleting the section completely to remove boilerplate text.

Necessary information

  • Is this a regression (i.e. did it work before)? {YES/NO} Maybe
  • What platform did you use? {Window/Linux/Mac} Linux (Ubuntu bash Docker)
  • What were the used arguments? None : A build error

Video links

None

Additional information

While runningmake after running the commands ./autogen.sh and ./configure there is an error namely

gcc -DPACKAGE_NAME=\"CCExtractor\" -DPACKAGE_TARNAME=\"ccextractor\" -DPACKAGE_VERSION=\"0.88\" -DPACKAGE_STRING=\"CCExtractor\ 0.88\" -DPACKAGE_BUGREPORT=\"carlos@ccextractor.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"ccextractor\" -DVERSION=\"0.88\" -DHAVE_LIBM=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MALLOC_H=1 -DHAVE_NETDB_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DHAVE__BOOL=1 -DHAVE_PTRDIFF_T=1 -DHAVE_FSEEKO=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ALARM=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_FLOOR=1 -DHAVE_FTRUNCATE=1 -DHAVE_GETHOSTBYNAME=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_INET_NTOA=1 -DHAVE_MBLEN=1 -DHAVE_MEMCHR=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 -DHAVE_MKDIR=1 -DHAVE_MODF=1 -DHAVE_POW=1 -DHAVE_REALPATH=1 -DHAVE_RMDIR=1 -DHAVE_SELECT=1 -DHAVE_SETLOCALE=1 -DHAVE_SOCKET=1 -DHAVE_SQRT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRCHR=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNDUP=1 -DHAVE_STRRCHR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -I.  -I../src/lib_ccx/ -I../src/thirdparty/gpacmp4/ -I../src/libpng/ -I../src/thirdparty/zlib/ -I../src/thirdparty/zvbi/ -I../src/thirdparty/lib_hash/ -I../src/thirdparty/protobuf-c/ -I../src/thirdparty -I../src/ -I../src/thirdparty/freetype/include/    -std=gnu99 -Wno-write-strings -Wno-pointer-sign -D_FILE_OFFSET_BITS=64 -DVERSION_FILE_PRESENT -DFT2_BUILD_LIBRARY -DGPAC_DISABLE_VTT -DGPAC_DISABLE_OD_DUMP -O3 -s -DGPAC_CONFIG_LINUX  -DGPAC_64_BITS   -g -O2 -MT ../src/lib_ccx/ccextractor-ccx_encoders_common.o -MD -MP -MF ../src/lib_ccx/.deps/ccextractor-ccx_encoders_common.Tpo -c -o ../src/lib_ccx/ccextractor-ccx_encoders_common.o `test -f '../src/lib_ccx/ccx_encoders_common.c' || echo './'`../src/lib_ccx/ccx_encoders_common.c
In file included from ../src/lib_ccx/ccx_encoders_common.c:4:0:
../src/lib_ccx/ocr.h:3:10: fatal error: png.h: No such file or directory
 #include <png.h>
          ^~~~~~~
compilation terminated.
Makefile:3355: recipe for target '../src/lib_ccx/ccextractor-ccx_encoders_common.o' failed
make: *** [../src/lib_ccx/ccextractor-ccx_encoders_common.o] Error 1

I know that it is not an error in the platform , as I have used build.sh to compile CCextractor correctly
The platform I'm using :
Ubuntu 18.04 on Docker , on MacOS

Upon comparing and investigating, it seems that png.h does exist in ../src/thirdparty/libpng/
Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well

This is not an included library in the Compilation page , for Autogen Scripts .Is there a reason behind this ?

Originally created by @vishwesh-D-kumar on GitHub (Mar 3, 2020). CCExtractor version: 0.88 # In raising this issue, I confirm the following: - [X] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [X] I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present. - [X] I have checked that the issue I'm posting isn't already reported. - [X] I have checked that the issue I'm porting isn't already solved and no duplicates exist in [closed issues](https://github.com/CCExtractor/ccextractor/issues?q=is%3Aissue+is%3Aclosed) and in [opened issues](https://github.com/CCExtractor/ccextractor/issues) - [X] I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion. - [X] I have used the latest available version of CCExtractor to verify this issue exists. - [X] I have ticked all the boxes in this section and to prove it I'm deleting the section completely to remove boilerplate text. # Necessary information - Is this a regression (i.e. did it work before)? {YES/NO} Maybe - What platform did you use? {Window/Linux/Mac} Linux (Ubuntu bash Docker) - What were the used arguments? None : A build error # Video links None # Additional information While running``` make ``` after running the commands ```./autogen.sh``` and ```./configure``` there is an error namely ``` gcc -DPACKAGE_NAME=\"CCExtractor\" -DPACKAGE_TARNAME=\"ccextractor\" -DPACKAGE_VERSION=\"0.88\" -DPACKAGE_STRING=\"CCExtractor\ 0.88\" -DPACKAGE_BUGREPORT=\"carlos@ccextractor.org\" -DPACKAGE_URL=\"\" -DPACKAGE=\"ccextractor\" -DVERSION=\"0.88\" -DHAVE_LIBM=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_LIMITS_H=1 -DHAVE_LOCALE_H=1 -DHAVE_MALLOC_H=1 -DHAVE_NETDB_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDINT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_WCHAR_H=1 -DHAVE__BOOL=1 -DHAVE_PTRDIFF_T=1 -DHAVE_FSEEKO=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_ALARM=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_DECL_STRERROR_R=1 -DHAVE_STRERROR_R=1 -DHAVE_FLOOR=1 -DHAVE_FTRUNCATE=1 -DHAVE_GETHOSTBYNAME=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_INET_NTOA=1 -DHAVE_MBLEN=1 -DHAVE_MEMCHR=1 -DHAVE_MEMMOVE=1 -DHAVE_MEMSET=1 -DHAVE_MKDIR=1 -DHAVE_MODF=1 -DHAVE_POW=1 -DHAVE_REALPATH=1 -DHAVE_RMDIR=1 -DHAVE_SELECT=1 -DHAVE_SETLOCALE=1 -DHAVE_SOCKET=1 -DHAVE_SQRT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRCHR=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNDUP=1 -DHAVE_STRRCHR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1 -I. -I../src/lib_ccx/ -I../src/thirdparty/gpacmp4/ -I../src/libpng/ -I../src/thirdparty/zlib/ -I../src/thirdparty/zvbi/ -I../src/thirdparty/lib_hash/ -I../src/thirdparty/protobuf-c/ -I../src/thirdparty -I../src/ -I../src/thirdparty/freetype/include/ -std=gnu99 -Wno-write-strings -Wno-pointer-sign -D_FILE_OFFSET_BITS=64 -DVERSION_FILE_PRESENT -DFT2_BUILD_LIBRARY -DGPAC_DISABLE_VTT -DGPAC_DISABLE_OD_DUMP -O3 -s -DGPAC_CONFIG_LINUX -DGPAC_64_BITS -g -O2 -MT ../src/lib_ccx/ccextractor-ccx_encoders_common.o -MD -MP -MF ../src/lib_ccx/.deps/ccextractor-ccx_encoders_common.Tpo -c -o ../src/lib_ccx/ccextractor-ccx_encoders_common.o `test -f '../src/lib_ccx/ccx_encoders_common.c' || echo './'`../src/lib_ccx/ccx_encoders_common.c In file included from ../src/lib_ccx/ccx_encoders_common.c:4:0: ../src/lib_ccx/ocr.h:3:10: fatal error: png.h: No such file or directory #include <png.h> ^~~~~~~ compilation terminated. Makefile:3355: recipe for target '../src/lib_ccx/ccextractor-ccx_encoders_common.o' failed make: *** [../src/lib_ccx/ccextractor-ccx_encoders_common.o] Error 1 ``` I know that it is not an error in the platform , as I have used ```build.sh``` to compile CCextractor correctly The platform I'm using : Ubuntu 18.04 on Docker , on MacOS Upon comparing and investigating, it seems that png.h does exist in ```../src/thirdparty/libpng/``` Upon searching for this issue, seems that running ```sudo apt-get install libpng-dev``` installs it correctly and ```make``` runs perfectly well This is not an included library in the Compilation page , for Autogen Scripts .Is there a reason behind this ?
claunia commented 2026-01-29 16:47:56 +00:00
Author
Owner
Copy Link

@canihavesomecoffee commented on GitHub (Mar 3, 2020):

libpng was more recently moved into the thirdparty folder, and the include in orc.h might not have been updated correctly.

It was moved in af6d8282cb, so maybe @NilsIrl can help out.

@canihavesomecoffee commented on GitHub (Mar 3, 2020): `libpng` was more recently moved into the `thirdparty` folder, and the include in `orc.h` might not have been updated correctly. It was moved in https://github.com/CCExtractor/ccextractor/commit/af6d8282cb53ff84c17b0ea44288e97943dbcc98, so maybe @NilsIrl can help out.
claunia commented 2026-01-29 16:47:56 +00:00
Author
Owner
Copy Link

@NilsIrl commented on GitHub (Mar 3, 2020):

The issue is that autogen wasn't updated (IIRC) for the movement of libraries to the thirdparty directory (unlike the other build systems).

Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well

Why do we ship libpng when we could use the system package?

@NilsIrl commented on GitHub (Mar 3, 2020): The issue is that autogen wasn't updated (IIRC) for the movement of libraries to the `thirdparty` directory (unlike the other build systems). > Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well Why do we ship libpng when we could use the system package?
claunia commented 2026-01-29 16:47:57 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (Mar 3, 2020):

Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well

Why do we ship libpng when we could use the system package?

In general we vendor libraries (except tesseract) to guarantee portability and availability. Remember that we also support Windows (in fact, like it or not, most of our users run Windows). Requiring external libraries in Windows is frowned upon.

@cfsmp3 commented on GitHub (Mar 3, 2020): > > Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well > > Why do we ship libpng when we could use the system package? In general we vendor libraries (except tesseract) to guarantee portability and availability. Remember that we also support Windows (in fact, like it or not, most of our users run Windows). Requiring external libraries in Windows is frowned upon.
claunia commented 2026-01-29 16:47:57 +00:00
Author
Owner
Copy Link

@vishwesh-D-kumar commented on GitHub (Mar 3, 2020):

@NilsIrl

The issue is that autogen wasn't updated (IIRC) for the movement of libraries to the thirdparty directory (unlike the other build systems).

It seems like the third party support has been configured into,as the makefile gcc command I quoted has all the thirdparty directories included via the -I option.

Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well

Why do we ship libpng when we could use the system package?

In general we vendor libraries (except tesseract) to guarantee portability and availability. Remember that we also support Windows (in fact, like it or not, most of our users run Windows). Requiring external libraries in Windows is frowned upon.

@cfsmp3 I totally missed that point, I can how see that the problems it would cause for windows!
I looked at the gcc command , and It seems that the command doesnt have the correct file path for libpng included.
I've figured the source of the error to be the wrong path on the Makefile.am

1b17a04b25/linux/Makefile.am (L321)
I'm correcting the path and submitting a pull request for the same ,
Ive tested it for the autoconf scripts , it has sucessfully compiled .
Do let me know if theres somewhere I went wrong :)

@vishwesh-D-kumar commented on GitHub (Mar 3, 2020): @NilsIrl > The issue is that autogen wasn't updated (IIRC) for the movement of libraries to the `thirdparty` directory (unlike the other build systems). > It seems like the third party support has been configured into,as the makefile gcc command I quoted has all the thirdparty directories included via the -I option. > > > Upon searching for this issue, seems that running sudo apt-get install libpng-dev installs it correctly and make runs perfectly well > > > > > > Why do we ship libpng when we could use the system package? > > In general we vendor libraries (except tesseract) to guarantee portability and availability. Remember that we also support Windows (in fact, like it or not, most of our users run Windows). Requiring external libraries in Windows is frowned upon. @cfsmp3 I totally missed that point, I can how see that the problems it would cause for windows! I looked at the gcc command , and It seems that the command doesnt have the correct file path for libpng included. I've figured the source of the error to be the wrong path on the Makefile.am https://github.com/CCExtractor/ccextractor/blob/1b17a04b25dbd6e7306d8cb499b7a28515ce6480/linux/Makefile.am#L321 I'm correcting the path and submitting a pull request for the same , Ive tested it for the autoconf scripts , it has sucessfully compiled . Do let me know if theres somewhere I went wrong :)
claunia commented 2026-01-29 16:47:58 +00:00
Author
Owner
Copy Link

@NilsIrl commented on GitHub (Mar 3, 2020):

Ive tested it for the autoconf scripts , it has sucessfully compiled .

Just to make sure, did you uninstall libpng-dev? (To make sure the change is what fixes the problem.)

@NilsIrl commented on GitHub (Mar 3, 2020): > Ive tested it for the autoconf scripts , it has sucessfully compiled . Just to make sure, did you uninstall `libpng-dev`? (To make sure the change is what fixes the problem.)
claunia commented 2026-01-29 16:47:58 +00:00
Author
Owner
Copy Link

@vishwesh-D-kumar commented on GitHub (Mar 3, 2020):

Just to make sure, did you uninstall libpng-dev? (To make sure the change is what fixes the problem.)

Yeah.
I double checked it by running apt-get remove libpng-dev gave the output :

Building dependency tree       
Reading state information... Done
Package 'libpng-dev' is not installed, so not removed

The testing suite also seems to work fine with it, I can see it has a test to check autoconf scripts.
:)

@vishwesh-D-kumar commented on GitHub (Mar 3, 2020): > Just to make sure, did you uninstall `libpng-dev`? (To make sure the change is what fixes the problem.) Yeah. I double checked it by running ```apt-get remove libpng-dev``` gave the output : ```Reading package lists... Done Building dependency tree Reading state information... Done Package 'libpng-dev' is not installed, so not removed ``` The testing suite also seems to work fine with it, I can see it has a test to check autoconf scripts. :)
claunia commented 2026-01-29 16:47:59 +00:00
Author
Owner
Copy Link

@NilsIrl commented on GitHub (Mar 3, 2020):

The testing suite also seems to work fine with it, I can see it has a test to check autoconf scripts.
:)

The autoconf scripts worked in the first place, they didn't catch the regression so...

It may be interesting to remove the packages that can hide regressions from the workflows.

@NilsIrl commented on GitHub (Mar 3, 2020): > The testing suite also seems to work fine with it, I can see it has a test to check autoconf scripts. > :) The autoconf scripts worked in the first place, they didn't catch the regression so... It may be interesting to remove the packages that can hide regressions from the workflows.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
CEA-708
difficulty: easy
difficulty: hard
difficulty: medium
DTMB
DVB
enhancement
enhancement
Flutter GUI
GCI19
good-first-task
GSoC 2021
GSOC-2023
GSOC-2023
GSOC-2023
GSoC-related
Hacktoberfest
HardsubX
help wanted
invalid
JokerTV
Mac / OSX
more-info-needed
needs-commercial-sponsor
needs-commercial-sponsor
needs-commercial-sponsor
needs-confirmation-of-being-broken
OCR
pull-request
Mirrored from GitHub Pull Request
 Python
regression
Rust
teletext
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/ccextractor#567
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?