From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24251 invoked by alias); 18 Jul 2012 08:42:40 -0000 Received: (qmail 24239 invoked by uid 22791); 18 Jul 2012 08:42:39 -0000 X-SWARE-Spam-Status: No, hits=-3.3 required=5.0 tests=AWL,BAYES_00,FSL_RCVD_USER,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,TW_JC X-Spam-Check-By: sourceware.org Received: from smtp2-g21.free.fr (HELO smtp2-g21.free.fr) (212.27.42.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Jul 2012 08:42:26 +0000 Received: from www.zeusw.org (unknown [82.231.68.224]) by smtp2-g21.free.fr (Postfix) with ESMTP id 2BE754B017B for ; Wed, 18 Jul 2012 10:42:18 +0200 (CEST) Received: from localhost ([::1] helo=zeusw.org) by www.zeusw.org with esmtp (Exim 4.72) (envelope-from ) id 1SrPpr-000238-EK for cygwin@cygwin.com; Wed, 18 Jul 2012 10:42:19 +0200 Received: from 192.168.5.10 (SquirrelMail authenticated user esc) by zeusw.org with HTTP; Wed, 18 Jul 2012 10:42:19 +0200 Message-ID: <727538151630afee0f9a37532ef80df1.squirrel@zeusw.org> In-Reply-To: <1342195424.30517.ezmlm@cygwin.com> References: <1342195424.30517.ezmlm@cygwin.com> Date: Wed, 18 Jul 2012 08:42:00 -0000 Subject: Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question) From: "Claude SIMON" To: cygwin@cygwin.com Reply-To: simon.claude@zeusw.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-07/txt/msg00355.txt.bz2 Ryan Johnson wrote: > On 13/07/2012 4:25 AM, Al Slater wrote: >> On 12/07/2012 16:59, Claude SIMON wrote: >>> Ryan Johnson wrote: >>>> >>>> [...] >>>> >>>> Sorry, I should have actually looked at the repo before assuming the >>>> test case was a monstrosity. By way of penance, I've now looked, >>>> downloaded, tweaked, and tested it. >>>> >>>> [...] >>>> >>> >>> Thanks for testing. >>> >>> I removed your test results (and the other stuff) from this message, >>> not >>> because I'm not interested into, but because I have a new problem, >>> which >>> prevents me to investigate further the original problem in the light of >>> your test results. >>> >>> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my >>> current configuration is now : >>> >>> Windows Vista 32 bits SP2 >>> Cygwin 1.7.15 >>> g++ 4.5.3 >>> javac 1.7.0_05 >>> javah 1.7.0_05 >>> java 1.7.0_05 >>> >>> When running the test case, I now have : >>> >>> $ java jcmc >>> Loading library 'jcmc'...Exception in thread "main" >>> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll: >>> L'accÞs >>> Ó cet emplacement de la mÚmoire n'est pas valide >>> at java.lang.ClassLoader$NativeLibrary.load(Native Method) >>> at java.lang.ClassLoader.loadLibrary1(Unknown Source) >>> at java.lang.ClassLoader.loadLibrary0(Unknown Source) >>> at java.lang.ClassLoader.loadLibrary(Unknown Source) >>> at java.lang.Runtime.loadLibrary0(Unknown Source) >>> at java.lang.System.loadLibrary(Unknown Source) >>> at jcmc.main(jcmc.java:9) >>> >>> There is a French message which roughly means "The access to this >>> memory >>> location is not valid" >>> >>> I updated the test case to reflect your changes : >>> - 'Makefile' now generates the '.h' file, >>> - 'Makefile' does no more contain the '--stdcall-alias' linker >>> flag, >>> - the '.cpp' contains now the `extern "C"' directive, >>> - the '.h' is removed from test case, since it's now generated by >>> the >>> 'Makefiile'. >>> >>> I have the new error message with this modified test case, but also >>> with >>> the original one. I suspect that the French error message is issued by >>> Cygwin or by one of its sub-component, since the JVM never issued a >>> message which wasn't in English, but Cygwin did. >>> >>> So, I have to postpone the study of the 'malloc()' related bug until I >>> manage to resolve this new issue ; I then come back to your test >>> results. >>> But, meanwhile, if someone has an idea why I have this new error... >>> >>> Here again the address where the test case can be found : >>> http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios >>> >> >> Does >> http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw >> provide any help? >> > > Or, just use mingw-gcc, like I suggested before: >> x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++ -c -g >> -Ijdk/include -Ijdk/include/win32 "-D__int64=long long" jcmc.cpp >> >> [...snip...] >> Mingw is a windows-targeted cross compiler that runs under cygwin but >> produces native windows binaries, so it doesn't have any posix >> functions available; the -static flags tell mingw to make a truly >> stand-alone executable that has only standard windows runtime >> dependencies. > > Just use i686-pc-mingw32-g++ if you're 32-bit, the rest stays the same. > Thanks! This is what I finally, and successfully, did. I updated the test case accordingly. However, I would like to use the Cygwin 'default' compiler, because this one is used more often as the 'MinGW' one and especially because I had to do some tweaks. I had to install the 'libcgj11' package (not a big deal), but also : - to copy '/usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_dw2-1.dll' in '/bin' - in '/bin', to make a copy of 'cyggcj-11.dll' and name it 'libgcj-11.dll'. Quite awful, isnt't it ? But without that, I didn't manage to make my component to be loaded. -- Claude SIMON http://zeusw.org/ -- 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