X-Spam-Check-By: sourceware.org From: "Dave Korn" To: Subject: RE: Fortran calling c compilation problem Date: Wed, 2 Aug 2006 15:11:35 +0100 Message-ID: <050501c6b63d$8ffc6160$a501a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44CF677A.3050707@statslab.cam.ac.uk> Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On 01 August 2006 15:39, Ben Wright wrote: > g++ -mno-cygwin -Wl,--add-stdcall-alias > -I/cygdrive/c/Java/jdk1.5.0_07/include > -I/cygdrive/c/Java/jdk1.5.0_07/include/win32 -shared -o Samplers.dll whole bunch of source files here> -lstdc++ -lg2c > > /cygdrive/c/DOCUME~1/ben/LOCALS~1/Temp/ccWWbiIF.o:gengam.f(.text+0x5): > undefined reference to `_dgamdv_' > (plus others of similar form) > > The linker can't seem to find references of the form _dgamdv_. Functions > are defined in the c portion as gdamdv_(), and are called from > Fortran as DGAMDV(). This works fine under Linux. Not quite sure why you would expect a function called _dgamdv_ to match one which is called gdamdv_XXXXXX. They appear to have very different names, and one has a suffix where the other doesn't. Is there some kind of typo in this para? > What's baffling is that if I compile just the c portion and inspect the > output with nm then the supposedly undefined references are in there. > > 10004148 T _dgamdv_ However, this suggests that the real problem is just that the source files are in the wrong (meaning non-dependency) order on the compiler command line, and hence on the linker command line. > Is there some quirk of cygwin when calling c from within fortran I need > to set a flag for when compiling? I'd ordinarily chalk it up to my weak > knowledge of c- but it compiles without complaint under Linux. This works fine on Linux where a shared lib can contain undefined references that are linked up at runtime, but it doesn't work on 'doze where a dll has to be fully resolved. To fix it, you could just reorder the source files into dependency order on the command-line, so that any file that refers to an undefined symbol comes *before* the file that supplies that symbol, or you could separate compiling and linking into two separate stages, and use the --start-group and --end-group options to wrap all the object files on the linker command line. cheers, DaveK -- Can't think of a witty .sigline today.... -- 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/