Closed jgottula closed 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?
/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.
@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.
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 .
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.
Well, nix is ssh'able again, so get to it!
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"
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>
containingCV_BayerBG2BGR
; instead it uses the namespace-scope enums directly in<opencv2/imgproc.hpp>
, including one containingCOLOR_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.)