Make77 error while installing Darknet on Windows - yolo

I am facing the Make77 problem. Can somebody help me out?
mingw32-make
gcc -Iinclude/ -Isrc/ -Wall -Wno-unused-result -Wno-unknown-pragmas -Wfatal-errors -fPIC -Ofast obj/captcha.o obj/lsd.o obj/super.o obj/art.o obj/tag.o obj/cifar.o obj/go.o obj/rnn.o obj/segmenter.o obj/regressor.o obj/classifier.o obj/coco.o obj/yolo.o obj/detector.o obj/nightmare.o obj/instance-segmenter.o obj/darknet.o libdarknet.a -o darknet -lm -pthread libdarknet.a
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: obj/go.o:go.c:(.text+0x329f): undefined reference to `__WSAFDIsSet#8'
c:/mingw/bin/../lib/gcc/mingw32/9.2.0/../../../../mingw32/bin/ld.exe: obj/go.o:go.c:(.text+0x32e1): undefined reference to `select#20'
collect2.exe: error: ld returned 1 exit status
Makefile:77: recipe for target 'darknet' failed
mingw32-make: *** [darknet] Error 1

I was in your shoes a few weeks ago and managed to fix that.
I am confident, you are trying to compile the original repository of Darknet on a Windows machine.
Cause
Unfortunately, one of the libraries used in go.c is *nix-only. It has a counterpart in Windows called winsock.h, but apparently it is not enough and the problem still persists.
Solution
Instead what you should do is use another repo of Darknet which is ported to Windows properly and has a lot of support. It has exactly the same functionality as the original repo except for very little changes which only makes the framework better. Instead of compiling with make command, you should build it with Microsoft Visual Studio. You may go with the latest version of MVS. If you want to use a GPU and install correctly, make sure you follow the instructions here https://github.com/AlexeyAB/darknet#requirements . To avoid any weird errors, install the requirements in order.
When all requirements are installed, navigate to build/darknet and open darknet.sln. Switch to Release and x64 and build the project.
That should be it. If you have any issues, let me know so I can help you. Also, if this solution works for you, make sure to mark my reply as the best answer.

Related

CocoaFob - linker command failed with exit code 1

This is a weird error! I'm getting:
ld: framework not found CocoaFob
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've checked all my build settings - and they appear correct. CocoaFob.framework is in my Linked Frameworks and Libraries - showing healthy and black. For some reason though, the damned framework isn't found when I try to link. Does anyone have any ideas?
Once possible clue is that when I try to the cocoafob application ( from here: https://github.com/glebd/cocoafob ) I get exactly the same error. I'm using Xcode 8.2.1
Okay. So the solution for me (and hopefully this will help anyone else who's experiencing a similar problem) was to:
build CocoaFob as release (I'd already done this, but in the interests of completeness) copy the resultant built framework to /Library/Frameworks and use it from there.
Do not attempt to use it in the location where it was built! Neither should you create a symlink in /Library/Frameworks to the location where it was built.
This done, all works well. Phew!

Homebrew doctor crashes

I just upgraded & updated my homebrew and now if I run brew doctor, I get the following errors and it fails to run. May I deleted the unexpected header files or is there a better solution?
Warning: Your XQuartz (2.7.6) is outdated
Please install XQuartz 2.7.7:
https://xquartz.macosforge.org
Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.
Unexpected header files:
/usr/local/include/node/ares.h
/usr/local/include/node/ares_version.h
/usr/local/include/node/eio-emul.h
/usr/local/include/node/ev-emul.h
/usr/local/include/node/node.h
/usr/local/include/node/node_buffer.h
/usr/local/include/node/node_object_wrap.h
/usr/local/include/node/node_version.h
/usr/local/include/node/uv-private/eio.h
/usr/local/include/node/uv-private/ev.h
/usr/local/include/node/uv-private/ngx-queue.h
/usr/local/include/node/uv-private/tree.h
/usr/local/include/node/uv-private/uv-unix.h
/usr/local/include/node/uv-private/uv-win.h
/usr/local/include/node/uv.h
/usr/local/include/node/v8-debug.h
/usr/local/include/node/v8-preparser.h
/usr/local/include/node/v8-profiler.h
/usr/local/include/node/v8-testing.h
/usr/local/include/node/v8.h
/usr/local/include/node/v8stdint.h
Basically, you just need to upgrade the XQuartz in your system and ignore all the other warnings.
You may build some software that utilise X11 components, so just go to https://xquartz.macosforge.org/, download and install the latest version.
It is obvious that you install node.js without using homebrew so that the header files are added into /use/local/include/ not via homebrew and confuse it. Unless you encounter some kind of problems as mentioned in the warning message, you can just ignore them.

f2py: limit.h file missing in numpy in Windows

I’m having trouble compiling some FortranIV code using f2py and the g77 compiler. I need to do this to call some very old code written in Fortran to an already existing Python module. I have gcc installed through MinGW but I’m not sure if that makes any difference. I am also running Python 2.7 with Numpy 1.7 and SciPy 0.12. My OS is Windows7 x64 but I have made sure that all my installs are 32bit versions. I am new to Python, Fortran and this forum so please bear with me.
The error I am getting when I compile the code with f2py is as follows:
C:\Python27\lib\site-packages\numpy\core\include\numpy\npy_common.h:291: limits.h: No such file or directory
error: Command "gcc -mno-cygwin -mdll -O2 -w -Wstrict-prototypes - DNPY_MINGW_USE_CUSTOM_MSVCR -D__MSVCRT_VERSION__=0x0900 - Ic:\users\ncd69~1.boh\appdata\local\temp\tmpxbl4sc\src.win32-2.7 -IC:\Python27\lib\site- packages\numpy\core\include -IC:\Python27\include -IC:\Python27\PC - c:\users\ncd69~1.boh\appdata\local\temp\tmpxbl4sc\src.win32-2.7\hellomodule.c -o c:\users\ncd69~1.boh\appdata\local\temp\tmpxbl4sc\Release\users\ncd69~1.boh\appdata\local\temp\tmpxbl4sc\src.win32-2.7\hellomodule.o" failed with exit status 1
In order to isolate the problem I have used a test code that is compatible with the gfortran compiler. I make a call to the required compilers using ‘-c –compiler. The test is on the same lines as your basic ‘Hello World’. The error thrown up is identical for the real and test code. I looked up the erroneous file ‘npy_common.h’ and found that line 291 calls to include a header: limits.h.
Since the error occurs in the Numpy libraries I am assuming that the error is with Numpy? I can’t seem to figure out why this error would occur.

Not getting TBB to compile test examples

I am not getting TBB to work. I am following the steps in the "Getting started" document.
I am doing the following steps:
downloading the linux files + the sources files.
extracting them in 1 directory
calling make
going to tbb.../bin calling source tbbvars.sh intel64
going to examples/Getting_started/sub_string_finder
calling make
I then get the error:
sub_string_finder.cpp:32:30: fatal error: tbb/parallel_for.h: No such file or directory
I really googled a lot but can't find any related stuff.
I did also try to add some -I statement but it didnt help
I assume it is kind of a including/linking problem but I dont know how to fix.
This is all done on fedora 16 64bit. (kernel 3.1.4) // TBB version 4.0
The solution was to install tbb-devel package.

Why would autoconf/automake project link against installed library instead of local development library?

I'm creating a library libgdata that has some tests and non-installed programs. I am running into the problem that once I've installed the library once, the programs seem to be linking to the installed version and not the local version in ../src/libgdata.la any longer.
What could cause this? Am I doing something horribly wrong?
Here is what my test/Makefile.am looks like:
INCLUDES = -I$(top_srcdir)/src/ -I$(top_srcdir)/test/
# libapiutil contains all of our dependencies!
AM_CXXFLAGS = $(APIUTIL_CFLAGS)
AM_LDFLAGS = $(APIUTIL_LIBS)
LDADD = $(top_builddir)/src/libgdata.la
noinst_PROGRAMS = gdatacalendar gdatayoutube
gdatacalendar_SOURCES = gdatacalendar.cc
gdatayoutube_SOURCES = gdatayoutube.cc
TESTS = check_bare
check_PROGRAMS = $(TESTS)
check_bare_SOURCES = check_bare.cc
(libapiutil is another library that has some helper stuff for dealing with libcurl and libxml++)
So, for instance, if I run the tests without having installed anything, everything works fine. I can make changes locally and they are picked up by these programs right away.
If I install the package, these programs will compile (it seems like it does actually look locally for the headers), but once I run the program it complains about missing symbols.
As far as I can tell, it is linking against the newly built library (../src/libgdata.la) based on the make output, so I'm not sure why this would be happening. If i remove the installed files, the local changes to src/* are picked up just fine.
I've included the make output for gdatacalendar below.
g++ -DHAVE_CONFIG_H -I. -I.. -I../src/ -I../test/ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -MT gdatacalendar.o -MD -MP -MF .deps/gdatacalendar.Tpo -c -o gdatacalendar.o gdatacalendar.cc
mv -f .deps/gdatacalendar.Tpo .deps/gdatacalendar.Po
/bin/bash ../libtool --tag=CXX --mode=link g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -L/home/altern8/workspaces/4355/dev-install/lib -lapiutil -lcurl -lgssapi_krb5 -lxml++-2.6 -lxml2 -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0 -o gdatacalendar gdatacalendar.o ../src/libgdata.la
mkdir .libs
g++ -I/home/altern8/workspaces/4355/dev-install/include -I/usr/include/libxml++-2.6 -I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -o .libs/gdatacalendar gdatacalendar.o -L/home/altern8/workspaces/4355/dev-install/lib /home/altern8/workspaces/4355/dev-install/lib/libapiutil.so /usr/lib/libcurl.so -lgssapi_krb5 /usr/lib/libxml++-2.6.so /usr/lib/libxml2.so /usr/lib/libglibmm-2.4.so /usr/lib/libgobject-2.0.so /usr/lib/libsigc-2.0.so /usr/lib/libglib-2.0.so ../src/.libs/libgdata.so -Wl,--rpath -Wl,/home/altern8/workspaces/4355/dev-install/lib
creating gdatacalendar
Help. :)
UPDATE
I get the following messages when I try to run the calendar program when I've added the addCommonRequestHeader() method to the Service class after I had installed the library without the addCommonRequestHeader() method.
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
symbol lookup error:
/home/altern8/workspaces/4355/libgdata/test/.libs/lt-gdatacalendar:
undefined symbol:
_ZN55gdata7service7Service22addCommonRequestHeaderERKSsS4_
Eugene's suggestion to try setting the $LD_LIBRARY_PATH variable did not help.
UPDATE 2
I did two tests. First, I did this after blowing away my dev-install directory (--prefix) and in that case, it creates test/.libs/lt-gdatacalendar. Once I have installed the library, though, it creates test/.libs/gdatacalendar instead. The output of ldd is the same for both with one exception:
# before install
# ldd test/.libs/lt-gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0 (0xb7c32000)
# after install
# ldd test/.libs/gdatacalendar
libgdata.so.0 => /home/altern8/workspaces/4355/dev-install/lib/libgdata.so.0 (0xb7c87000)
What would cause this to create lt-gdatacalendar in one case but gdatacalendar in another?
The output of ldd on libgdata is:
altern8#goldfrapp:~/workspaces/4355/libgdata$ ldd /home/altern8/workspaces/4355/libgdata/src/.libs/libgdata.so.0
linux-gate.so.1 => (0xb7f7c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7f3b000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dec000)
/lib/ld-linux.so.2 (0xb7f7d000)
I think I've sorted this out.
The problem should be that libtool sees the "-L" flag in the command line before it sees the "../src/libgdata.so" part. In this case, it executes the linker with "-Wl,-rpath,..." for that "-L" path. If that path contains "libgdata.so", then it will always be used, which is the case here.
In my case, I've rearranged "prog_LDADD" to like like this:
"prog_LDADD = $(top_builddir)/src/my_lib.so $(DEPENDENCY_LIBS)"
In your case, try to delete AM_LDFLAGS and write:
LDADD = $(top_builddir)/src/libgdata.la $(APIUTIL_LIBS)
Not sure how to do that in autoconf, but final command might need to have -L../src, so linker can find newly built library first.
Try manually running last command with that addition and see if that helps.
EDIT: Ok, I guess misread it, thought it wasn't linking, but you are saying it links but doesn't run?
If that is the case, run ldd on your binary and see which .so it picks up -- most likely installed (and outdated) ones.
In this case, either install updated libs before running, or export LD_LIBRARY_PATH env variable before running.
export LD_LIBRARY_PATH="/path to freshly built libs"
I know that for dependencies to work correctly, you need to refer to libgdata.la with a relative path in LDADD; it's possible that affects the situation you're describing as well.
I'm not sure why, though. The behavior you're describing does seem a bit odd; and perhaps worth reporting to the libtool developers.
Without -no-install libtool creates script wrappers and puts the executables into the .libs/ subdir (linked with the installed libraries). Calling the wrapper makes your executable load/link with your local (not installed) library - so everything works fine, e.g. make check does not test the installed but your freshly baken library.
In some cases (e.g. when debugging or valgrinding), you do not want to have those wrappers, but real executables directly linked with your local library. For this you use AM_LDFLAGS = -no-install (or just set it for single targets).
More details here