I see, so pd-lib-builder is not an option.
It is an automake system, but I can't tell if it builds (or if it is meant to build) to a single binary or not. It does look like Gem's, and the compilation aftermath looks very similar, too.
The reason why I think it's not a single binary is that the old release I have (i think from deken) contains one binary per source.
Is there a way to check if pix_opencv is a single binary build? e.g, How/Where is single binary achieved in Gem?
On Mar 1, 2019, at 8:39 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 3/1/19 2:00 AM, Fede Camara Halac wrote: ok. i think you can discard my last email. It turns out i was loading the old 32bit i had. my bad.
but
i did some more digging and the reason pd does not load the externals is that they dont exist.
so? your original error was when loading pix_opencv.pd_darwin. most likely, pix_opencv is single binary with multiple objects (or put otherwise: ther isn't a pix_rgba.pd_darwin either)
somehow the only object built is pix_opencv.pd_darwin, which just fires a console welcome message. The rest of the pix_opencv_*.pd_darwin objects are not created. Only their *.o are there and they *can* be used to make their respective ps_darwins (tried with one and worked, loaded and all :)
First, I dont know why this last step of the linking is just not happening. How can I make sure this is not something missing from the generated Makefile?
Second, I dont fully understand these makefiles. Can this all be done easier with pd-lib-builder? I am tempted to try and do something like that.
i don't know the pix_opencv makefile, but pd-lib-builder is not really targetted at complex build systems with lots of dependencies.
fgmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list