Re: opencv python bindings

[Pete Flugstad]

On Wed, Jan 17, 2018 at 12:48 PM, szgyg  wrote:

> Different packages, python2-cv2 and python3-cv2.
>

Oh man, I'm such an idiot.  I was looking all over for opencv packages,
didn't think to look for cv2 packages.

In any case, Thanks!

Pete

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

opencv python bindings

[Pete Flugstad]

Hello,

uname:  CYGWIN_NT-10.0  2.9.0(0.318/5/3) 2017-09-12 10:18 x86_64
Cygwin

Running on Windows 10.

I've installed the opencv(3.2) and libopencv3.2 packages, but those
packages apparently didn't contain the python bindings (cv2)?

The opencv_version.exe -v indicates that the python2 bindings were to be
built.  Did they just not get package, or is it in a different package I'm
not seeing?

Pip couldn't find a version that works either (not surprising).

Thanks,
Pete

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: using Cygwin (-mno-cygwin) to JNI to a 3rd party DLL

[Pete Flugstad]

On 5/1/07, Brian Dessent <[EMAIL PROTECTED]> wrote:

You'll have to run this in a debugger to be sure, but I'd start looking
at calling convention clashes, i.e. stdcall vs cdecl.  This should be a
function of the header files and how they declare prototypes.


The thing that's odd is that without the 3rd party DLL present, everything
works just fine.  My JNI functions are called and work (just debug printouts
in that case).  Only when I actually call the 3rd party DLL (and obviously
I'm linking against it), does it fail - and it fails before it even
tries to call
a function - during the loading phase.


This is not the right list.  When using -mno-cygwin you aren't using any
of Cygwin, you're essentially cross compiling to MinGW.  So their
mailing list would probably be the right place to ask.


I'll go ask there.  Thanks!!!


The gcc list is
*never* the right place to ask anything relating to debugging program
crashes, unless you can actually identify a specific compiler bug (which
it never is, 99.999% of the time.)


Good to know.

Thanks!
Pete

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

using Cygwin (-mno-cygwin) to JNI to a 3rd party DLL

[Pete Flugstad]

Hello,

 We have a 3rd party Windows DLL that we want to interface with from Java,
obviously using JNI.  The 3rd party DLL provides a link lib to link
against.  It's
a pure C interface (no C++).  I've used the 3rd party DLL just fine for a while
now from MSVC (ver 6), but now we want to call it from Java.

 I've been trying to use Cygwin's GCC with -mno-cygwin to build the JNI
portion - that maps from the JNI call to the actual DLL call -
basically following
the Inonit tutorial ().  I've done
this before very successfully (for rebuilding rxtx serial lib) but not
with a 3rd
party DLL in the mix.

 I've tested out all the JNI stuff by commenting out all the calls to
the 3rd party
DLL, and I can get from Java to the native C code just fine.

 But when I add the 3rd party DLL calls back in (and link against the
link lib),
everything links OK, but when I try and run it, I get an error from the JVM:

  Load Error: myJni.dll: Invalid access to memory location
 java.lang.UnsatisfiedLinkError: myJni.dll: Invalid access to
memory location
   at java.lang.ClassLoader$NativeLibrary.load(Native Method)
   at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
   at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
   at java.lang.Runtime.loadLibrary0(Runtime.java:822)
   at java.lang.System.loadLibrary(System.java:993)
   at com.test.jniTest.main(miniAce.java:33)

 Now, I copied the 3rd party DLL to the same directory as my DLL, and as
I'm running this from (and '.' in in my PATH, and in java's
system.library.path).
And I still get the same problem.

 I setup the same C code under MSVC and generate with that, and it works
just fine.  In looking at the MSVC generated DLL, I see that it's symbol names
have an underscore '_' on the front of them, while the GCC -mno-cygwin
generated ones do not.   I don't know that that matters, as when I built without
the 3rd party DLL, it still works.

 It seems like maybe there is some problem with the JVM and loading dependent
libs?   But I thought that that was something that Windows did, not
the JVM?  (we're
using Sun's JVM, 1.5.0_11).

 Eventually I would like to use SWIG to automate wrapping the 3rd
party DLL's API,
but I want to get over this hurdle first.

 I realize this may not be the right place for this question - it may
be more GCC
related than Cygwin related (especially since I'm using -mno-cygwin),
but I know the
guys who did a lot work on LD to make this work are here.  I'm maybe hoping
someone here has seen this before?  Alternatively, what is the right
place for this
question - the main GCC mailing list?  Or maybe it's a Sun/JVM question?

Thanks,
Pete

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: GNU make and VPATH problems

[Pete Flugstad]

Pete Flugstad wrote:
   So, before I start trying to debug GNU make, has anyone seen anything 
like this?  I'll work on recreating the problem with a simplified setup, 
so I can post an example here, but I'm hoping someones seen this before.
Getting no response, I downloaded the GNU make 3.80-1 sources from:

  http://mirrors.kernel.org/sources.redhat.com/cygwin/release/make/

and do a configure/build with -g.   And it works just fine.  No problem 
finding the source files in VPATH.

Just to make sure, I compared my binary /usr/bin/make.exe to the one 
from the .tar.bz2 file downloaded from the above URL, and they were 
identical.

Seems like maybe an GCC optimization bug somewhere, which my debug build 
doesn't trigger?

Pete

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

GNU make and VPATH problems

[Pete Flugstad]

Greetings,

I just recently started having a problem with GNU make.  I believe
it's related to VPATH, but I'm not sure.  The weird part is that I think 
it just recently started happening after I ran the cygwin update (which 
did not update GNU make).  I checked the mailing list archvies and I 
don't see anything that seems relevant/related.

For various reasons, I have created a GNUmakefile to build the 
OpenSSL crytpo lib using the Tornado (vxWorks) tools (gcc based 
basically) on Windows 2000 SP3.  The crypto lib has a lot of files 
(370+), spread out over probably 30+ sub-dirs.  I setup the directory 
structure to have a GNUmakefile at the top level, with a src/ directory 
with all the crypto sources in it and an obj/ directory where I want all 
the .o's built.  I setup the makefile to use all relative paths using 
'/' as a seperator.  I setup a VPATH to refer to all the source dirs, 
again, just simple unix style paths, no spaces, or weird DOS characters. 
 Here's the VPATH:

VPATH = src:src/asn1:src/bf:src/bio:src/cast:src/comp:src/bn:\
src/conf:src/des:src/dh:src/dsa:src/dso:src/err:\
src/evp:src/hmac:src/lhash:src/md2:src/md4:src/buffer:\
src/md5:src/mdc2:src/objects:src/pem:src/pkcs12:src/pkcs7:\
src/rand:src/rc2:src/rc4:src/ripemd:src/rsa:\
src/sha:src/stack:src/x509:src/x509v3:src/misc
I would normally just use the make that comes with Tornado (ver
3.74), and that generally works just fine, except a couple of the build
steps require some shell scripting that doesn't work with command.com.
So I have been runing GNU make under cygwin for this step, which up 
until a recently has been just fine.

  Now however, after and update to cygwin, when I run cygwin GNU make, 
it acts like it can't seem to find some of the dirs in the VPATH, 
complaining that it has no rule to build the required object files. 
However, it finds .c files in the peer directories just fine.  And 
moving the problem directories around in the VPATH doesn't help either. 
 It's like it thinks that the VPATH directive doesn't apply to those 
directories, or it can't find them.

  The exact same makefile on Linux with GNU make 3.80 works just fine. 
 The same setup with the Tornago GNU make 3.74 works just fine (except 
for the steps that require the shell scripting).

  As a quick example, one of the problem directories is "src/bn".  I 
ran GNU make with -dd for a .c file in the src/bss dir (which works 
fine) and for a .c file in a problem dir.  Here's when it's looking for 
the "good" one:

Considering target file `obj/bss_log.o'.
 File `obj/bss_log.o' does not exist.
 Looking for an implicit rule for `obj/bss_log.o'.
 Trying pattern rule with stem `bss_log'.
 Trying implicit prerequisite `bss_log.c'.
 Found prerequisite `bss_log.c' as VPATH `src/bio/bss_log.c'
 Trying rule prerequisite `algo_defines.h'.
 Found prerequisite `algo_defines.h' as VPATH `src/algo_defines.h'
And here's one where the src/bn directory seems to not be found, even 
though it's in my VPATH:

Considering target file `obj/bn_add.o'.
 File `obj/bn_add.o' does not exist.
 Looking for an implicit rule for `obj/bn_add.o'.
 Trying pattern rule with stem `bn_add'.
 Trying implicit prerequisite `bn_add.c'.
 Trying pattern rule with stem `bn_add'.
 Trying implicit prerequisite `obj/bn_add.c'.
 Trying pattern rule with stem `bn_add'.
  so src/bn and src/bss are both on there (I've tried moving src/bn 
around, it doesn't matter).  The .c files are in those directories, but 
it finds one, but not the other.  The other problem dirs are src/dso, 
src/md5 and src/rc4.  These seem consistent, regardless of where I put 
them in the VPATH.

  I've checked the permissionns on these directories, and they are all 
identical.  I'm actually mounting the whole tree from a Linux box using 
a samba share, and mapping that to a drive letter.  And as I noted 
above, the same GNUmakefile on the Linux system works just fine.  All 
the permissions on the Linux dirs are identical and they all appear 
identical on the Windows box.

  So, before I start trying to debug GNU make, has anyone seen anything 
like this?  I'll work on recreating the problem with a simplified setup, 
so I can post an example here, but I'm hoping someones seen this before.

Thanks,
Pete


--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/