Problem getting ofxHTTP to work

Running version 10.1 on linux arch.

In running the examples in ofxHTTP getting a bunch of errors that look like:

... /addons/ofxPoco/libs/poco/lib/linux64/libPocoNetSSL.a(Context.o):Context.cpp:function Poco::Net::Context::createSSLContext(): error: undefined reference to 'SSLv23_client_method'

There are some past posts about some incompatibility between some versions of openSSL and the version of poco bundled with of but I don’t see clear instructions concerning how to fixt it (if that is indeed the problem).

Any help would be appreciated.

Steve

Poco should be used from the system packages in newer distros instead of the packaged version. In ubuntu the install_dependencies script takes care of this but not yet on archlinux.

This is the bit that fixes ofxPoco/addons_config.mk to use poco from the system instead of the packaged version:

if [[ $MAJOR_VERSION -gt 18 || $MAJOR_VERSION -eq 18 ]]; then
    PACKAGES="libpoco-dev"
    echo "detected ubuntu 18.04 or greater"
    echo "OF needs to install poco libraries in the system with the following packages:"
    echo ${PACKAGES}
    if [ "$1" != "-y" ]; then
        read -p "Do you want to continue? [Y/n] "
        if [[ $REPLY =~ ^[Nn]$ ]]; then
            exit 0
        fi

        echo
        echo "Installing..."
        echo
    fi
    installPackages ${PACKAGES}
    cp $ROOT/../extra/poco_config.mk $ROOT/../../../addons/ofxPoco/addon_config.mk
fi

if you or anyone else wants to adapt it to archlinux and want to send a PR with the fixes that would be really useful

Happy to try to fix this for arch. One question:

if/when is addon_config.mk (located in ofxPoco) being read? I have changed addon_config.mk it so that it should be using arch system libraries for poco (which are in /usr/lib) and for good measure I have removed the poco libraries in the ofxPoco subdirectory yet when I compile a sample app from scratch, it is still looking in ofxPoco/libs/... for the libraries and I am not sure where that directive is coming from. I am new to OF and would appreciate some direction and suspect the answer is obvious.

Thanks,

Steve

the makefiles or the qtcreator project parse that file to know which libraries, files and flags to include.

if you open the file in scripts/extra/poco_config.mk you’ll see how to modify the file and really just copying that file as ofxPoco/addons_config.mk and installing poco in the system using pacman should work right away

Yes, that’s exactly what I did but when I compile it’s still looking in the sub-directories of ofxPoco for the libraries so it doesn’t seem to be reading the new addon_config.mk that’s in the ofxPoco folder. I’ll keep at it since it must be something obvious I am overlooking.

Last attempt. Is there any other conceivable place that would be directing the compiler to look for the libs in

.../ofxPoco/libs/poco/linux64

because despite the changes to addon_config.mk, it continues to look there. And this is with a full rebuild of of. In the compile output I do see the expected -lPocoNetSSL -lPocoCrypto etc etc but
the compile fails with messages like:

g++: error: /home/slzatz/of_v0.10.1_new/addons/ofxPoco/libs/poco/lib/linux64/libPocoCrypto.a: No such file or directory

And it’s true those libraries (which we don’t want to use) have been moved/deleted but they are still being looked for in the compilation process. As far as I can tell, what I have done is exactly the same as what worked for ubuntu although the package to install in arch is poco v. libpoco-dev in Ubuntu but the arch package contains the header files (that the compiler isn’t finding).

Never mind. I have two versions of qt creator – the one recommended in the OF download instructions and the arch pacman installed version. I have been using the OF-recommended version – how this possibly relates to the library issue I encountered I have no idea, but I just ran the same example using ofxPoco but compiled via the pacman-installed version of qt creator and it compiled and ran so I can confirm that the solution for Ubuntu works on arch as well.