dimitre commented 1 month ago

I'm helping a friend to debug some issues on Visual Studio and I think the issue now is about using Poco with LibPNG because things get duplicated. What can be done to help? maybe build Poco without PDF support? It uses ofxVideoRecorder which adds poco (only for Poco::condition) Maybe std::condition_variable can be used in ofxVideoRecorder ? Ideas are welcome. thank you cc: @danoli3 @timscaffidi

dimitre commented 1 month ago

we had it working by copying older libraries (04/2023) from a different OF installation and overwriting the actual (from 12/2023)

danoli3 commented 1 month ago

Got you thinking with the sub-dependancy problems, oh they are the bane of the Linker

Yes so the problem here is Poco has been built with a prepackaged LibPNG sub-dependancy as part of their core (ssl also) : Like soooo many libraries that use other libraries, if they are not name spaced or used correctly in the library, this sort of madness occurs and its just not clear at all to the dev

Good news is we can compile anything by linking to their dependancy and using shared one that we build and link to our binaries and force the library to not package in their code the dependancy, and this will solve the linking problems and grant all libraries access to the functions of that lib (hopefully, shall check)

This is a main problem I had with FreeImage for example as their sub dependancies were always so out of date it lead to people getting absolutely hacked to oblivion as well as packaging all the exploits like LibPNG remote executions that load in every messenger app, yeepppppp. I patched out LibPNG for example to be able to be passed to the FreeImage CmakeList compiler and it worked so hence why we get LibPNG as a seperate lib - As its used by other libraries too - FreeImage linking to other libs didn't work. Side effect though is this problem we can't use a prepackaged FreeImage if also linking to LibPNG in our libs as that prepackaged lib/binary has a pre-packaged libpng without namespace and will do this bug.

So when you see linking errors like this, it's usually a bigger problem like outdated libs in the project can make a project or computer very vulnerable when running that code not to mention

But you can start to see how everything is linkeddddddd LOL

danoli3 commented 1 month ago

I actually have an updated Poco Formulae, okay lets see what we can do with this

danoli3 commented 1 month ago

I had a Quick Look haha check this out in their cmakelist:

# TODO: Currently only bundled is supported, in future this should also be possible
# with an unbundled version of libpng
POCO_SOURCES(SRCS libpng
    src/png.c
    src/pngerror.c
    src/pnggccrd.c
    src/pngget.c
    src/pngmem.c
    src/pngpread.c
    src/pngread.c
    src/pngrio.c
    src/pngrtran.c
    src/pngrutil.c
    src/pngset.c
    src/pngtest.c
    src/pngtrans.c
    src/pngvcrd.c
    src/pngwio.c
    src/pngwrite.c
    src/pngwtran.c
    src/pngwutil.c
)

guess I'll patch that for them

danoli3 commented 3 weeks ago

Another solution is as well make LibPNG able to be to defined out in the core, maybe all libraries should be able to be defined out to solve similar issues though.

define NO_LIBPNG

danoli3 commented 6 days ago

Poco libraries subdependancy audit: for (libpng, zlib)

openframeworks / apothecary

Visual Studio - libpng symbols duplicated in poco? #382

define NO_LIBPNG