ccextractor 0.74 has been out for a while now and was curious if a version bump can be made. I have succesfully build it from source so I know it runs. Thanks ahead of time.
Created attachment 387280 [details] 0.74 build 0.74 build, builds using provided libs so everything works and other libs are not needed.
(In reply to Daniel Witzel from comment #1) > Created attachment 387280 [details] > 0.74 build > > 0.74 build, builds using provided libs so everything works and other libs > are not needed. Yah, that's not gonna fly. I don't want it using internal copies of the deps (which is why I haven't put together an ebuild myself ... haven't gotten around to fixing it).
I took a stab at decoupling this, but it's pretty exhausting, so I'm going to report my findings and see if someone else wants to take up the torch. The tarball ships also with source code of gpac, libpng, zlib, lib_cxx, zvbi, lib_hash, utf8proc, and protobuf-c. I managed to remove internal deps and link against current libs for png, zlib, zvbi, utf8proc and protobuf-c (see patch). lib_cxx is a separate library that gets built against, and it looks like it could go into its own ebuild if we wanted to. I'm fine with it building and linking against itself right here, though. lib_hash is actually just an include of a sha2.c, sha2.h. I'm fine with that, too. Currently, the ebuild just calls gcc directly, after pulling in the required dependencies. We could follow that path as well. Here's the 0.69 line for reference: $(tc-getCXX) ${CXXFLAGS} ${LDFLAGS} -DHAVE_LIBPNG -DGPAC_CONFIG_LINUX -D_FILE_OFFSET_BITS=64 -Igpacmp4/ -o ccextractor $(find . -name '*.cpp') $(find . -name '*.c') -lpng || die It's gpac that is a pain in the butt, since it compiles against its source code (not libraries) directly. I'm not sure what the best way to fix something like that is .. maybe unpack our gpac at the same time and have it link to that? Upstream has two build systems that both work to create the binary, a Makefile and a build script. I poked at both of them to get the same results. It's worth noting that the binary *does build* just fine with both of those changes in the patch, so it looks like we have some leeway when it comes to modifying, making, or replacing the build approach. There's so many _optional_ dependencies that I'd consider just throwing together some autotools scripts -- it's really not that complex.
Created attachment 486134 [details, diff] ccextractor-src-nowin.0.85.zip patch
Since we have 0.85 in tree, this bug is probably obsolete. Everyone interested in this package please head over to bug 651524 (0.86 version bump).
