Eclipse
DLLs
x64
Win10 isn't unix, but they are suffering from castration envy. As
everybody knows, eunuchs are missing a vital organ so they cannot perform.
The Windoze development team are trying really hard to make their product
harder to use than OSX, and for their part, Apple
is trying even harder to make that very very difficult. Both succeeded.
Only the real Linux (and of course DOS) could possibly
be worse. I think it's somehow appropriate that Win10 greets me with a
big frown every time it asks me for a password -- which is waaay too often
for a computer that is used by me alone in the privacy of my house and
and no connection to the internet (air-gap firewall). But the whole unix
security model (which everybody uses, not just the unixies) is broken.
The date & time thing is broken. Turn off the "Adjust automatically" because it makes the date run backwards, and while the minutes of the time track, it sets it to some random time zone (so the hours are wrong).
The most important thing to realize is that everything is "Cloud" based, which means it is incredibly unstable, changing all the time, breaking everything. Get used to it, it's the real world, it's the way the power mongers abuse the noobs. The unixies think all the difficulty makes for job security, and they are right -- but the secure jobs are in India and Belarus, not here. The Bigger Picture is that you succeed when you help other people to succeed, which means making it easier for them, not harder. <end flame>
VisualStudio is no longer functional. This was confirmed by my Windows guru. They worked so hard to make it a "cloud" product, that it no longer works at just compiling a simple DLL in non-cloud mode. Forget VS.
Naw, you just gotta install the C/C++ compiler when you install it, it cannot be upgraded afterwards (just delete the whole thing = restore from before it was installed, and reinstall it).
Eclipse (as its name, which is Greek for "failure", implies) is a failure, just not as bad as VS. I followed the instructions here:
http://www.multigesture.net/articles/how-to-install-mingw-msys-and-eclipse-on-windows/Don't skip any steps, it fails. One of the things they tell you to do is add MinGW to the PATH variable. They don't tell you how to find this PATH variable. Other people couldn't find it either, but the online answers to their question tend to be abusive put-downs. So here it is plain and as simple as things can be in a system that is trying to be as difficult as the abusive answers to online questions about it are:
Right-click the window button in the bottom left corner and select "Control Panel" from the popup menu.Choose "System" then "Advanced System Settings" from the list on the left of the new window. That pops up another window with an "Environment Variables" button near the bottom.
Yet another popup window, where "Path" is in the list in the lower panel. Click on it and choose "Edit" for a fifth window, where you can insert exactly one path. This being Windoze-trying-to-be-eunuchs, you must have memorized what you want there and then type it all in manually and hit "OK" (or else it discards what you've partly completed), then repeatedly click the "Move Up" button to get it to the front where the MultiGesture instructions tell you to put it. Do this twice, once for each path.
Think of it as job security (in India), where your employment status is likely to get exported to because it takes you too long to do what the Mac would have done for you automagically when you said "Install." The camera API I'm trying to interface this to was done by professionals and their installer did all that (meaning: it's already there :-)
MinGW is said to be good only for 32-bit, not 64. 64-bit code is
bigger and slower (unless you actually need 64-bit data, but what for?)
so that shouldn't be a problem -- until you try to run the compiled DLL
in JNI. My computer came with 64-bit Java already
installed, and Eclipse is written in Java (and therefore runs really really
slow, because the Java runtime engine must recompile all the byte code
down to x86 machine code each time you start it up), so you need to install
the version of Eclipse that matches the Java you have. 32-bit MinGW probably
runs as a command-line sub-task, so it doesn't matter what's under the
hood in Eclipse, but that's not the problem. So I get to do this all over
again with 64-bit MingGW, which might be available here
(I found this link in StackOverflow,
which also explained the problem). You also need to select MinGW from the
tool set each time, but this is a eunuchs port, nobody expects them to
do anything right.
Anyway, it worked for me today. Tomorrow, who knows? It's internet-based, so unstable.
This version of Eclipse is slightly better than the one I downloaded
for OSX last year, because you can delete the workspace
and it reverts to its initial welcome screen. Tomorrow, who knows? It's
so unstable. That's the nature of "cloud" computing.
One of the early warnings in the Eclipse blog is that Windoze can't find your DLLs unless you put their directories into the PATH (see above). The blog tells you to do it in the User Control Panel, but you can't. Repeat the process above. Their screen shots show the workspace in the "C:" root directory, but it isn't, you must type in a long path through Users. If you want things to be fast, go find an old Mac (not OSX), but of course you can't do anything modern there. sigh Anyway, it seems to be OK to leave this new path at the end of the list, you only need it to find your new code which has a unique name, right?
The teenage (of all ages) hackers who build and maintain unixy tools like Eclipse and especially MinGW do not understand legacy code compatibility. So the Eclipse blog tells you to use "cygdrive" but it's broken with Msys. When the video game method (randomly try different things until something works) fails, Google comes to the rescue (meaning with all these broken tools, other people have hit the same problems, and somebody somewhere offers a fix. I never heard of Nabble, but there it is: instead of " /cygdrive/C:" (error "No such file or directory") just omit the "cygdrive" reference (so it's "/C"). Anyway it still didn't work and I have not yet found anybody to explain why.
Hmmm, it looks like MinGW might be too lame to get at random header files from some random location in the local file system, see the MinGW Wiki on "How to Specify the Header File Include Path". I guess for now I get to copy all .h files into the MinGW include directory, and maybe all the compiled .dll files into its bin directory. If that works. It solved the problem with the compiler finding the .h file, but now it complains that it "cannot find -lmymath" (or maybe it's "-Imymath", I can't tell, they chose an ambiguous font to display messages and I can't find how to change it, or maybe like OSX there isn't anything better on this turkey). I have no idea what it wants nor where it wants to see it. I Googled the error message, and apparently gcc is so bad, there were a zillion posts with the same error message even in Linux. I tried all the fixes suggested by the posted answers, including making copies of all the files in the existing folders where gcc should be looking, but to no avail. I'm not surprised, nothing unix has ever worked for me ever.
I'm giving up on (failed) Eclipse, moneybags is willing to pay for VS: https://www.visualstudio.com/vs/professional/
StackOverflow
(after some anti-noob abuse) gives advice for making a DLL in VS-C, then
links to (encrypted) MSDN
for more. I'm still stuck trying to link a previously compiled DLL into
a test program, but the Point Grey FlyCapture2 SDK includes VS "Solution"
files, one of which compiled successfully linking to their own DLLs. The
compiled program didn't run, error 0xc000007b (x86/x64 platform incompatibility),
so now I have a question in to the Point Grey support center asking for
help. We shall see.
Point Grey responded: It seems everybody offers x64 versions of their code, you just gotta know to ask for it. Things started working in 2017 March, and so I stopped adding to this rant -- until today, I fixed some misspellings.
Rev. 2018 May 11