seeing-things / zwo

ZWO SDK and custom software for debugging and using it.
24 stars 4 forks source link

PR for #3, #8 #11

Closed jgottula closed 5 years ago

jgottula commented 5 years ago

This PR addresses both of those issues.

00e0538 is the main commit here, and has a fair bit of text "under-the-fold" in the commit description.

The other two commits are minor fixups.

ac039cb fixes up some things that currently don't matter terribly much since zwo_fixer currently operates without the need for anyone else to include its header file or call any functions or basically do anything explicitly. (It's all automatic-at-library-load-time right now, but that might change in the future; hence the existence of the header, ZWOFixerInit, etc.)

b729297 addresses the fact that OpenCV 4.x doesn't automatically pull in the global-scope enum from <opencv2/imgproc/types_c.h> containing CV_BayerBG2BGR; instead it uses the namespace-scope enums directly in <opencv2/imgproc.hpp>, including one containing COLOR_BayerBG2BGR. (The up-to-date library documentation indicates that the latter enums should be preferred. Also, the #include "opencv2/imgproc/imgproc_c.h" statement in OpenCV 3.x's <opencv2/imgproc.hpp> is wrapped in #ifndef DISABLE_OPENCV_24_COMPATIBILITY, so it appears to be a deprecated thing anyway.)

bgottula commented 5 years ago

On nix I got:

rgottula@nix ~/dev/zwo/capture $ make
make -C ../zwo_fixer all
make[1]: Entering directory '/home/rgottula/dev/zwo/zwo_fixer'
g++ -std=c++17 -fno-exceptions -fno-strict-aliasing -D_GLIBCXX_USE_CXX11_ABI=0 -fdiagnostics-color=always -Wall -Wno-unused-variable -Wno-unused-function -O1 -fuse-linker-plugin -fvisibility=hidden -fvisibility-inlines-hidden -g3 -gdwarf-4 -fvar-tracking-assignments -fno-omit-frame-pointer -fuse-ld=gold -shared -fPIC -fno-plt -fno-gnu-unique -rdynamic -Wl,--no-gc-sections -Wl,--no-undefined -Wl,-z,defs -lbsd -ldl -lelf -lusb-1.0 -DZWO_VERSION_MAJOR=0 -DZWO_VERSION_MINOR=7 -DZWO_VERSION_REVISION=503 -DZWO_VERSION_STRING=\"0.7.0503\" -DZWO_VERSION=0x00070503U -o libzwo_fixer.so zwo_fixer.cpp
/usr/bin/ld.gold: error: cannot find -lelf
collect2: error: ld returned 1 exit status
Makefile:30: recipe for target 'libzwo_fixer.so' failed
make[1]: *** [libzwo_fixer.so] Error 1
make[1]: Leaving directory '/home/rgottula/dev/zwo/zwo_fixer'
Makefile:53: recipe for target 'bin/capture' failed
make: *** [bin/capture] Error 2

Did you test this on nix?

jgottula commented 5 years ago
/usr/bin/ld.gold: error: cannot find -lelf

Okay, it looks like zwo_fixer has a dependency on the libelf-dev package. I've installed that on nix and it links fine now.

Probably that should be documented in, uh... the README for capture, I suppose? Doesn't exist yet so I'm not 100% sure what to do there.


Also after this fix, I noticed that the linker was being too clever for its own good and secretly not-actually-linking-to-zwo_fixer because it didn't think anything was being directly used in the library by the capture program. Which, strictly speaking, would be an accurate assessment; but we want the damn thing to actually be linked in so that zwo_fixer will be loaded up by the runtime linker and then do its library-load-time fixups.

So that's what 02ade87 and 175dec1 are for. By explicitly calling a function in libzwo_fixer.so, the linker now actually realizes that it needs to link the damn library, and so it always does. This has been tested and confirmed on nix to make things work properly. No idea why the linker didn't do this "optimization" stuff on my machine. Must have different automatic/implicit linker flags from the distribution, I guess.

jgottula commented 5 years ago

@bgottula, let me know if zwo_fixer's shiny colorful debug logging is annoying or too verbose or whatever. If so, I can make that a conditional thing.

I'm pretty sure it only emits logging messages at startup, exit, and whenever it actually catches one of the USB error conditions that it corrects the behavior of. So hopefully that's not too much.

bgottula commented 5 years ago

Excellent, I'll try this out tonight.

Could you go ahead and create a README for capture with at least that dependency information?

On Tue, Jan 22, 2019 at 12:50 PM Justin Gottula notifications@github.com wrote:

@bgottula https://github.com/bgottula, let me know if zwo_fixer's shiny colorful debug logging is annoying or too verbose or whatever. If so, I can make that a conditional thing.

I'm pretty sure it only emits logging messages at startup, exit, and whenever it actually catches one of the USB error conditions that it corrects the behavior of. So hopefully that's not too much.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/seeing-things/zwo/pull/11#issuecomment-456558188, or mute the thread https://github.com/notifications/unsubscribe-auth/AG_AGiEqsKn17laXfNi_IdQrgnDOXM5oks5vF3mRgaJpZM4aMI8j .

jgottula commented 5 years ago

Could you go ahead and create a README for capture with at least that dependency information?

Yeah, but only once nix is ssh'able again so I can run dpkg on stuff and make sure any other dependencies (libusb, opencv, libbsd perhaps) are documented with the package name and whatnot.

bgottula commented 5 years ago

Well, nix is ssh'able again, so get to it!

jgottula commented 5 years ago

Dependencies seem to be as follows.

zwo_fixer

-lbsd: libbsd-dev
-ldl: libc6-dev
-lelf: libelf-dev
-lusb-1.0: libusb-1.0-0-dev
-lrt: libc6-dev
-lpthread: libc6-dev

capture

-lopencv_core: libopencv-core-dev
-lopencv_highgui: libopencv-highui-dev
-lopencv_imgproc: libopencv-imgproc-dev
-lusb-1.0: libusb-1.0-0-dev
-lrt: libc6-dev
-lpthread: libc6-dev

Also:

build-essential

I will write this README "soon"