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

[BUG] CCX on apple silicon #625

New Issue
Closed
opened 2026-01-29 16:49:22 +00:00 by claunia · 13 comments
claunia commented 2026-01-29 16:49:22 +00:00
Owner
Copy Link

Originally created by @NilsIrl on GitHub (Mar 29, 2021).

CCExtractor version: 19da837232

On apple silicon (M1), ccextractor doesn't compile.

[100%] Linking C executable ccextractor
ld: warning: directory not found for option '-L/opt/local/lib'
Undefined symbols for architecture arm64:
  "_png_init_filter_functions_neon", referenced from:
      _png_init_filter_functions in pngrutil.c.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [ccextractor] Error 1
make[1]: *** [CMakeFiles/ccextractor.dir/all] Error 2
make: *** [all] Error 2
Originally created by @NilsIrl on GitHub (Mar 29, 2021). CCExtractor version: https://github.com/CCExtractor/ccextractor/commit/19da837232cd2ecf3b6c528a0100ad0a6d152abd On apple silicon (M1), ccextractor doesn't compile. ``` [100%] Linking C executable ccextractor ld: warning: directory not found for option '-L/opt/local/lib' Undefined symbols for architecture arm64: "_png_init_filter_functions_neon", referenced from: _png_init_filter_functions in pngrutil.c.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [ccextractor] Error 1 make[1]: *** [CMakeFiles/ccextractor.dir/all] Error 2 make: *** [all] Error 2 ```
claunia commented 2026-01-29 16:49:22 +00:00
Author
Owner
Copy Link

@NauSakaguchi commented on GitHub (Mar 30, 2021):

I added -DPNG_ARM_NEON_OPT=0 flag to build.command file.
BLD_FLAGS="-DPNG_ARM_NEON_OPT=0 -std=gnu99 -Wno-write-strings -Wno-pointer-sign -DGPAC_CONFIG_DARWIN -D_FILE_OFFSET_BITS=64 -DVERSION_FILE_PRESENT -Dfopen64=fopen -Dopen64=open -Dlseek64=lseek -DFT2_BUILD_LIBRARY -DGPAC_DISABLE_VTT -DGPAC_DISABLE_OD_DUMP"

19da837232/mac/build.command (L3)

It is explained here:
dbe3e0c43e/pngpriv.h (L126-L128)

It works for me. So I think you can set the flag if you just want to compile ccextractor. However, the flag turns off the ARM NEON optimization.
Since The latest update of libpng is on March 3, 2019 (M1 is released in 2020 though), it might need to update. How do you think?

@NauSakaguchi commented on GitHub (Mar 30, 2021): I added *-DPNG_ARM_NEON_OPT=0* flag to [build.command file](https://github.com/CCExtractor/ccextractor/blob/19da837232cd2ecf3b6c528a0100ad0a6d152abd/mac/build.command). `BLD_FLAGS="-DPNG_ARM_NEON_OPT=0 -std=gnu99 -Wno-write-strings -Wno-pointer-sign -DGPAC_CONFIG_DARWIN -D_FILE_OFFSET_BITS=64 -DVERSION_FILE_PRESENT -Dfopen64=fopen -Dopen64=open -Dlseek64=lseek -DFT2_BUILD_LIBRARY -DGPAC_DISABLE_VTT -DGPAC_DISABLE_OD_DUMP"` https://github.com/CCExtractor/ccextractor/blob/19da837232cd2ecf3b6c528a0100ad0a6d152abd/mac/build.command#L3 It is explained here: https://github.com/glennrp/libpng/blob/dbe3e0c43e549a1602286144d94b0666549b18e6/pngpriv.h#L126-L128 It works for me. So I think you can set the flag if you just want to compile _ccextractor_. However, the flag turns off the ARM NEON optimization. Since The latest update of _libpng_ is on March 3, 2019 (M1 is released in 2020 though), it might need to update. How do you think?
claunia commented 2026-01-29 16:49:22 +00:00
Author
Owner
Copy Link

@schoeps commented on GitHub (Apr 2, 2021):

I think it would be generally great if ccextractor would rely on system libraries then this problem would disappear. There is some more discussion at homebrew on this: https://github.com/Homebrew/homebrew-core/pull/72218

@schoeps commented on GitHub (Apr 2, 2021): I think it would be generally great if ccextractor would rely on system libraries then this problem would disappear. There is some more discussion at homebrew on this: https://github.com/Homebrew/homebrew-core/pull/72218
claunia commented 2026-01-29 16:49:23 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (Apr 2, 2021):

I think it would be generally great if ccextractor would rely on system libraries then this problem would disappear. There is some more discussion at homebrew on this: Homebrew/homebrew-core#72218

The reason for having vendored stuff is pretty much Windows.

@cfsmp3 commented on GitHub (Apr 2, 2021): > I think it would be generally great if ccextractor would rely on system libraries then this problem would disappear. There is some more discussion at homebrew on this: [Homebrew/homebrew-core#72218](https://github.com/Homebrew/homebrew-core/pull/72218) The reason for having vendored stuff is pretty much Windows.
claunia commented 2026-01-29 16:49:23 +00:00
Author
Owner
Copy Link

@schoeps commented on GitHub (Apr 2, 2021):

The reason for having vendored stuff is pretty much Windows.

I understand but for other OS (Mac, Linux) it would be great to supply an install script that tries to use the system libs. Homebrew seems willing to kick the formula because of this (by the way: sorry, for derailing the original post but it seemed to fit here).

@schoeps commented on GitHub (Apr 2, 2021): > The reason for having vendored stuff is pretty much Windows. I understand but for other OS (Mac, Linux) it would be great to supply an install script that tries to use the system libs. Homebrew seems willing to kick the formula because of this (by the way: sorry, for derailing the original post but it seemed to fit here).
claunia commented 2026-01-29 16:49:23 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (Apr 3, 2021):

I understand but for other OS (Mac, Linux) it would be great to supply an install script that tries to use the system libs.

Why, what do we get for the effort at this point? The versions we're using are testing with our code, and being realistic we're not keeping up with changes on our dependencies.

We have to be pragmatic here (by that I mean who is going to do and maintain the changes)

@cfsmp3 commented on GitHub (Apr 3, 2021): > I understand but for other OS (Mac, Linux) it would be great to supply an install script that tries to use the system libs. Why, what do we get for the effort at this point? The versions we're using are testing with our code, and being realistic we're not keeping up with changes on our dependencies. We have to be pragmatic here (by that I mean who is going to do and maintain the changes)
claunia commented 2026-01-29 16:49:23 +00:00
Author
Owner
Copy Link

@schoeps commented on GitHub (Apr 3, 2021):

Why, what do we get for the effort at this point? The versions we're using are testing with our code, and being realistic we're not keeping up with changes on our dependencies.

The Gentoo linux distribution has assembled a collection of arguments:
https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies.

@schoeps commented on GitHub (Apr 3, 2021): > Why, what do we get for the effort at this point? The versions we're using are testing with our code, and being realistic we're not keeping up with changes on our dependencies. The Gentoo linux distribution has assembled a collection of arguments: https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies.
claunia commented 2026-01-29 16:49:23 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (May 2, 2021):

Why, what do we get for the effort at this point? The versions we're using are testing with our code, and being realistic we're not keeping up with changes on our dependencies.

The Gentoo linux distribution has assembled a collection of arguments:
https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies.

https://www.youtube.com/watch?v=Pzl1B7nB9Kc

@cfsmp3 commented on GitHub (May 2, 2021): > > Why, what do we get for the effort at this point? The versions we're using are testing with our code, and being realistic we're not keeping up with changes on our dependencies. > > The Gentoo linux distribution has assembled a collection of arguments: > https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies. https://www.youtube.com/watch?v=Pzl1B7nB9Kc
claunia commented 2026-01-29 16:49:24 +00:00
Author
Owner
Copy Link

@schoeps commented on GitHub (May 3, 2021):

https://www.youtube.com/watch?v=Pzl1B7nB9Kc

Interesting! I watched the video and I tend to agree (from the perspective of a proprietary software vendor). I am not sure if this should apply for software like ccextractor... but on the other hand, I am not with the dependency police.

Posting this video implicitly suggests that homebrew should remove ccextractor from its packaging, right? This is also what the homebrew maintainers suggested anyway and this is also fine for me. I have no strong opinion here. I know how to fix and compile code from source if I need to. So, I prefer to not "waste my life" (quote from the video!) any further :)

@schoeps commented on GitHub (May 3, 2021): > https://www.youtube.com/watch?v=Pzl1B7nB9Kc Interesting! I watched the video and I tend to agree (from the perspective of a proprietary software vendor). I am not sure if this should apply for software like ccextractor... but on the other hand, I am not with the dependency police. Posting this video implicitly suggests that homebrew should remove ccextractor from its packaging, right? This is also what the homebrew maintainers suggested anyway and this is also fine for me. I have no strong opinion here. I know how to fix and compile code from source if I need to. So, I prefer to not "waste my life" (quote from the video!) any further :)
claunia commented 2026-01-29 16:49:24 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (May 3, 2021):

Posting this video implicitly suggests that homebrew should remove ccextractor from its packaging, right?

I don't use a Mac or homebrew so I don't know. But I think distributions enforcing compilation / linking options over the convenience of developers and users (and the maintainer themselves!) is a very bad idea. There's nothing wrong with a binary having small static libraries embedded if they do what they are supposed to do.

Let's not make our lives (and our users) lives harder for the sake of some philosophy.

@cfsmp3 commented on GitHub (May 3, 2021): > Posting this video implicitly suggests that homebrew should remove ccextractor from its packaging, right? I don't use a Mac or homebrew so I don't know. But I think distributions enforcing compilation / linking options over the convenience of developers and users (and the maintainer themselves!) is a very bad idea. There's nothing wrong with a binary having small static libraries embedded if they do what they are supposed to do. Let's not make our lives (and our users) lives harder for the sake of some philosophy.
claunia commented 2026-01-29 16:49:25 +00:00
Author
Owner
Copy Link

@bbgdzxng1 commented on GitHub (Jun 21, 2021):

Just tested on 0.89 using brew and looks like there are still some challenges, pretty much as expected. But I thought I would give it a try with homebrew 0.89 anyway.

% brew install --build-from-source ccextractor
==> Downloading https://github.com/CCExtractor/ccextractor/archive/v0.89.tar.gz
==> Downloading from https://codeload.github.com/CCExtractor/ccextractor/tar.gz/
          
==> ./build.command
Last 15 lines from /Users/REDACTED/Library/Logs/Homebrew/ccextractor/01.build.command:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/secure/_string.h:111:9: note: previous definition is here
#define strlcpy(dest, ...) \
        ^
1 warning generated.
Undefined symbols for architecture arm64:
  "_png_do_expand_palette_rgb8_neon", referenced from:
      _png_do_expand_palette in pngrtran-01e874.o
  "_png_do_expand_palette_rgba8_neon", referenced from:
      _png_do_expand_palette in pngrtran-01e874.o
  "_png_init_filter_functions_neon", referenced from:
      _png_init_filter_functions in pngrutil-ffdc39.o
  "_png_riffle_palette_neon", referenced from:
      _png_do_read_transformations in pngrtran-01e874.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

On the assumption that the issue is the aforementioned -DPNG_ARM_NEON_OPT=0, does anyone know how the brew script https://github.com/Homebrew/homebrew-core/blob/master/Formula/ccextractor.rb can be modified to disable neon? Or is this an upstream issue with libpng? Please excuse my ignorance - I'm just a user, not a dev.

@bbgdzxng1 commented on GitHub (Jun 21, 2021): Just tested on 0.89 using brew and looks like there are still some challenges, pretty much as expected. But I thought I would give it a try with [homebrew 0.89](https://github.com/Homebrew/homebrew-core/commit/d0b00b51c70c9b46276db67cd20b23118f57fbad#diff-548b7d885b6d33672e123ebae0906b265cc2656297d2feb7db85828426a08993) anyway. ``` % brew install --build-from-source ccextractor ==> Downloading https://github.com/CCExtractor/ccextractor/archive/v0.89.tar.gz ==> Downloading from https://codeload.github.com/CCExtractor/ccextractor/tar.gz/ ==> ./build.command Last 15 lines from /Users/REDACTED/Library/Logs/Homebrew/ccextractor/01.build.command: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/secure/_string.h:111:9: note: previous definition is here #define strlcpy(dest, ...) \ ^ 1 warning generated. Undefined symbols for architecture arm64: "_png_do_expand_palette_rgb8_neon", referenced from: _png_do_expand_palette in pngrtran-01e874.o "_png_do_expand_palette_rgba8_neon", referenced from: _png_do_expand_palette in pngrtran-01e874.o "_png_init_filter_functions_neon", referenced from: _png_init_filter_functions in pngrutil-ffdc39.o "_png_riffle_palette_neon", referenced from: _png_do_read_transformations in pngrtran-01e874.o ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` On the assumption that the issue is the aforementioned `-DPNG_ARM_NEON_OPT=0`, does anyone know how the brew script https://github.com/Homebrew/homebrew-core/blob/master/Formula/ccextractor.rb can be modified to disable neon? Or is this an upstream issue with libpng? Please excuse my ignorance - I'm just a user, not a dev.
claunia commented 2026-01-29 16:49:26 +00:00
Author
Owner
Copy Link

@alebcay commented on GitHub (Jul 13, 2021):

FYI @bbgdzxng1 ccextractor 0.89 is now available on Homebrew for Apple Silicon - just brew install ccextractor.

@alebcay commented on GitHub (Jul 13, 2021): FYI @bbgdzxng1 `ccextractor` 0.89 is now available on Homebrew for Apple Silicon - just `brew install ccextractor`.
claunia commented 2026-01-29 16:49:26 +00:00
Author
Owner
Copy Link

@cfsmp3 commented on GitHub (Jul 14, 2021):

Closing since it seems to be done already

@cfsmp3 commented on GitHub (Jul 14, 2021): Closing since it seems to be done already
claunia commented 2026-01-29 16:49:27 +00:00
Author
Owner
Copy Link

@bbgdzxng1 commented on GitHub (Jul 21, 2021):

brew is working nicely on 0.90 for me now. At release, 0.89 did not install through brew, but perhaps someone updated the brewfile. Anyway, 0.90 is working really well on M1 Silicon. Thankyou all, especially @alebcay.

@bbgdzxng1 commented on GitHub (Jul 21, 2021): brew is working nicely on 0.90 for me now. At release, 0.89 did not install through brew, but perhaps someone updated the brewfile. Anyway, 0.90 is working really well on M1 Silicon. Thankyou all, especially @alebcay.
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#625
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?