I guess this issue relates #833 . In macOS, I couldn't build uselib and get this error.
g++ -std=c++11 -Wall -Wfatal-errors -Wno-unused-result -Wno-unknown-pragmas -Ofast -fPIC -o uselib src/yolo_console_dll.cpp -lm -pthread -L ./ -l:darknet.so
src/yolo_console_dll.cpp:248:16: warning: unused variable 'save_output_videofile' [-Wunused-variable]
bool const save_output_videofile = true;
^
src/yolo_console_dll.cpp:242:17: warning: unused variable 'thresh' [-Wunused-variable]
float const thresh = (argc > 5) ? std::stof(argv[5]) : 0.20;
^
2 warnings generated.
ld: library not found for -l:darknet.so
clang: fatal error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [uselib] Error 1
My Makefile ($ head Makefile) is
GPU=0
CUDNN=0
CUDNN_HALF=0
OPENCV=0
AVX=0
OPENMP=0
LIBSO=1
# set GPU=1 and CUDNN=1 to speedup on GPU
# set CUDNN_HALF=1 to further speedup 3 x times (Mixed-precision using Tensor Cores) on GPU Tesla V100, Titan V, DGX-2
The version of GCC which is a wrapper of LLVM is
Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.10.44.2)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
And we can build with changing LIBNAMESO=darknet.so to LIBNAMESO=libdarknet.so like #833 .
Is it a LLVM's error? If it isn't, would you like to change the value of LIBNAMESO?
And it's off-topic, I'd like to This API in macOS and Linux. Can I build dll with This Makefile?
If you use LIBNAMESO=darknet.so then will be created darknet.so file or libdarknet.so file?
Try to leave LIBNAMESO=darknet.so
and change -l:$(LIBNAMESO) to darknet.so here https://github.com/AlexeyAB/darknet/blob/7762372e5bba9e9411ee12d535b578159ca9043f/Makefile#L126
Ah, I can build with your way, I changed like this.
diff --git a/Makefile b/Makefile
index 10cee6d..6726909 100644
--- a/Makefile
+++ b/Makefile
@@ -4,7 +4,7 @@ CUDNN_HALF=0
OPENCV=0
AVX=0
OPENMP=0
-LIBSO=0
+LIBSO=1
# set GPU=1 and CUDNN=1 to speedup on GPU
# set CUDNN_HALF=1 to further speedup 3 x times (Mixed-precision using Tensor Cores) on GPU Tesla V100, Titan V, DGX-2
@@ -123,7 +123,7 @@ $(LIBNAMESO): $(OBJS) src/yolo_v2_class.hpp src/yolo_v2_class.cpp
$(CPP) -shared -std=c++11 -fvisibility=hidden -DYOLODLL_EXPORTS $(COMMON) $(CFLAGS) $(OBJS) src/yolo_v2_class.cpp -o $@ $(LDFLAGS)
$(APPNAMESO): $(LIBNAMESO) src/yolo_v2_class.hpp src/yolo_console_dll.cpp
- $(CPP) -std=c++11 $(COMMON) $(CFLAGS) -o $@ src/yolo_console_dll.cpp $(LDFLAGS) -L ./ -l:$(LIBNAMESO)
+ $(CPP) -std=c++11 $(COMMON) $(CFLAGS) -o $@ src/yolo_console_dll.cpp $(LDFLAGS) -L ./ darknet.so
endif
$(EXEC): $(OBJS)
Can I propose you this change as a pull request?
Thank you for updating your project, for this issue.
Yes, I added commit with this fix.
This issue doesn't seem fixed in master. The suggested line to change above still exist as before, and causes the same error on MacOS
https://github.com/AlexeyAB/darknet/blob/7a854302efb7adba80d5e8a747ad5e5ec384a226/Makefile#L131-L133
Changing this line to the following removes the error (but I have downstream errors in the package I'm developing linked to the .so file not being dylib compliant, which I'm trying to figure out.. which may be a different issue)
$(CPP) -std=c++11 $(COMMON) $(CFLAGS) -o $@ src/yolo_console_dll.cpp $(LDFLAGS) -L ./ $(LIBNAMESO)
@ianshmean
Currently LIBNAMESO is changed from darknet.so to libdarknet.so https://github.com/AlexeyAB/darknet/blob/7a854302efb7adba80d5e8a747ad5e5ec384a226/Makefile#L50
so it should work on MacOS.
Also you can try to use Cmake that makes it work successfully on any MacOS, Ubuntu and Windows:
With the make process on master I see:
ld: library not found for -l:libdarknet.so
so the change to libdarknet.so didn't seem to fix it for me. However the change I did above did fix it, and I'm now functional.
On a side note, for a MacOS build, the libdarknet extension should be .dylib not .so to play nicely with other packages that check for lib file types against standard practice, so I wonder whether that would be something to point out in the file, incase the user doesn't know that nuance. (that was tripping me up)
I haven't tried Cmake, would that fix that .dylib issue?
@ianshmean
I haven't tried Cmake, would that fix that .dylib issue?
I didn't try it on MacOS. If you can try it, we will think about fix it.