Re: [f2py] Compiling/linking the Fortran source files manually
Pearu Peterson <[email protected]> Tue, 26 Apr 2011 13:12:12 +0300
| Newsgroups | gmane.comp.python.f2py.user |
|---|---|
| Message-ID | <[email protected]> |
Great! At least there exists a solution to the original problem. Note that numpy/distutils/mingw32compiler.py has a hook dealing with exported symbols, only python dll ones though.. Best regards, Pearu On 04/26/2011 01:02 PM, Ben Forbes wrote: > Well I don't believe it. It seems to always happen like this, you give > up on something, then have a sudden realisation and fix it. > > The problem was that the .dll was not exporting any symbols. I > manually forced it to export inithelloworld() using the linker flag > "/export:inithelloworld" and lo and behold it works. It may become > necessary to export more symbols for more complicated examples, but > apparently this process can be automated with some clever scripting. > > > On Tue, Apr 26, 2011 at 7:43 PM, Ben Forbes<[email protected]> wrote: >> It works straight away on Linux. >> >> On Tue, Apr 26, 2011 at 7:29 PM, Ben Forbes<[email protected]> wrote: >>> I might try it on Linux instead, at least then the toolchains won't be >>> so painful to use. At the moment I have MinGW, MSys, cygwin all >>> fighting each other, to the point where "make" has stopped working. My >>> only real goal is to wrap a series of MKL FFT calls and run it from >>> Python, which I can do from Linux anyway. >>> >>> Thanks for your help, I'll post again if I have trouble on Linux. >>> >>> On Tue, Apr 26, 2011 at 7:22 PM, Pearu Peterson >>> <[email protected]> wrote: >>>> >>>> >>>> On 04/26/2011 12:12 PM, Ben Forbes wrote: >>>>> I've already modified the preprocessor directives to get the Fortran >>>>> routines mangled properly. inithelloworld() is already compiled >>>>> correctly, based on the object dump above. The problem must be the >>>>> Visual Studio linker doing its own mangling. >>>> >>>>> I'm using Enthought, it might be tricky to change my numpy. >>>> >>>> Yes, it could. >>>> >>>> In past I have used the following approach (no guarantees though): >>>> 1) rename enthought python folder >>>> 2) install python and numpy from scratch, you might need to install >>>> mingw as well as IIRC then enthought keeps mingw in its own directory >>>> 3) try the example >>>> 4) remove the installed software from 2) >>>> 5) rename enthought python folder back >>>> >>>>> Could this be one of those situations where GNU + Windows = Fail? >>>> >>>> Perhaps, I don't know, may be it is GNU + Intel + Visual = Fail >>>> >>>> However note that I am quite ignorant regarding Windows dll issues. >>>> >>>> Pearu >>>> >>>>> On Tue, Apr 26, 2011 at 7:05 PM, Pearu Peterson >>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On 04/26/2011 11:55 AM, Ben Forbes wrote: >>>>>>> No, I believe there is still a mangling issue. Python gives an error >>>>>>> along the lines of "can't find inithelloworld()". >>>>>> >>>>>> Can you establish what is the corresponding symbol name in the .pyd >>>>>> file? Perhaphs one or a combination of the following cpp options >>>>>> >>>>>> -DPREPEND_FORTRAN -DNO_APPEND_FORTRAN -DUPPERCASE_FORTRAN >>>>>> -DUNDERSCORE_G77 >>>>>> >>>>>> will help to fix the name mangling issue. These options ought to be >>>>>> used when compiling the foomodule.c file. >>>>>> >>>>>> Also, could you try the example with the latest numpy? >>>>>> >>>>>> Pearu >>>>>> >>>>>>> On Tue, Apr 26, 2011 at 6:50 PM, Pearu Peterson >>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 04/26/2011 11:33 AM, Ben Forbes wrote: >>>>>>>>> Okay I had copied intel.py in the same directory, so it was loading it twice. >>>>>>>>> >>>>>>>>> I changed >>>>>>>>> >>>>>>>>> 'linker_so' : ['<F90>', "-shared"], >>>>>>>>> >>>>>>>>> to >>>>>>>>> >>>>>>>>> 'linker_so' : ['<F90>', "/dll"], >>>>>>>>> >>>>>>>>> but it's still putting it in the wrong place: >>>>>>>>> >>>>>>>>> C:\Program Files (x86)\Intel\Compiler\11.1\067\bin\intel64\ifort.exe >>>>>>>>> /dll /dll foomodule.o fortranobject.o helloworld.o -LC:\Python27\libs >>>>>>>>> -LC:\Python27\PCbuild\amd64 -lpython27 /OUT:.\foo.pyd >>>>>>>>> >>>>>>>>> The /dll flag needs to be after /link, right at the end. Is this a >>>>>>>>> flaw with distutils? >>>>>>>> >>>>>>>> This is new to me. Can you give a reference for this condition? >>>>>>>> >>>>>>>> Note that there are two '/dll' in row, just in case it matters.. >>>>>>>> >>>>>>>> I don't see any '/link' option in the above command. >>>>>>>> >>>>>>>> Finally, when you execute the command above with the right order >>>>>>>> of all options, will foo.pyd be OK? Can you import it and call it from >>>>>>>> Python? >>>>>>>> >>>>>>>> Pearu >>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Apr 26, 2011 at 6:26 PM, Ben Forbes<[email protected]> wrote: >>>>>>>>>> I'm attempting to implement that, but there's suddenly another problem: >>>>>>>>>> >>>>>>>>>> C:\Users\bdforbes\pyfor\simple_f2py>f2py -c -m foo helloworld.f90 >>>>>>>>>> --fcompiler=intelvem >>>>>>>>>> Forcing DISTUTILS_USE_SDK=1 >>>>>>>>>> Traceback (most recent call last): >>>>>>>>>> File "C:\Python27\Scripts\f2py-script.py", line 24, in<module> >>>>>>>>>> main() >>>>>>>>>> File "C:\Python27\lib\site-packages\numpy\f2py\f2py2e.py", line 561, in main >>>>>>>>>> run_compile() >>>>>>>>>> File "C:\Python27\lib\site-packages\numpy\f2py\f2py2e.py", line 447, >>>>>>>>>> in run_compile >>>>>>>>>> fcompiler.load_all_fcompiler_classes() >>>>>>>>>> File "C:\Python27\lib\site-packages\numpy\distutils\fcompiler\__init__.py", >>>>>>>>>> line 736, in load_all_fco >>>>>>>>>> mpiler_classes >>>>>>>>>> fcompiler_aliases[alias][1].__name__)) >>>>>>>>>> ValueError: alias 'ifort' defined for both IntelFCompiler and IntelFCompiler >>>>>>>>>> >>>>>>>>>> I can't remember what changed to make this happen. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Apr 26, 2011 at 5:58 PM, Pearu Peterson >>>>>>>>>> <[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 04/26/2011 10:49 AM, Ben Forbes wrote: >>>>>>>>>>>> Modifying PATH makes it find the 64-bit compiler now. However, I'm >>>>>>>>>>>> still getting the same issues with the compiler and linker flags: >>>>>>>>>>>> >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/shared' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/shared' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/LC:\Python27\libs' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option >>>>>>>>>>>> '/LC:\Python27\PCbuild\amd64' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/lpython27' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/OU' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/OT' >>>>>>>>>>>> ifort: command line warning #10155: ignoring option '/optimize'; >>>>>>>>>>>> argument required >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/O.' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/O\' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/Of' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/Oo' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/Oo' >>>>>>>>>>>> ifort: command line warning #10006: ignoring unknown option '/O.' >>>>>>>>>>>> ifort: command line remark #10010: option '/Op' is deprecated and will >>>>>>>>>>>> be removed in a future release. >>>>>>>>>>>> See '/help deprecated' >>>>>>>>>>>> ifort: command line warning #10148: option '-Oy' not supported >>>>>>>>>>> >>>>>>>>>>> They are all warnings and therefore can be ignored... except >>>>>>>>>>> that '/shared' and '/lpython27' options should be fixed. >>>>>>>>>>> Consult the compiler help to find out how to properly >>>>>>>>>>> specify these options and modify intel.py accordingly. >>>>>>>>>>> >>>>>>>>>>> HTH, >>>>>>>>>>> Pearu >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> f2py-users mailing list >>>>>>>>>>> f2py-users-Y4l6ocDipWCuvFJfX82//[email protected] >>>>>>>>>>> http://cens.ioc.ee/mailman/listinfo/f2py-users >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Benjamin D. Forbes >>>>>>>>>> School of Physics >>>>>>>>>> The University of Melbourne >>>>>>>>>> Parkville, VIC 3010, Australia >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> f2py-users mailing list >>>>>>>> f2py-users-Y4l6ocDipWCuvFJfX82//[email protected] >>>>>>>> http://cens.ioc.ee/mailman/listinfo/f2py-users >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> f2py-users mailing list >>>>>> f2py-users-Y4l6ocDipWCuvFJfX82//[email protected] >>>>>> http://cens.ioc.ee/mailman/listinfo/f2py-users >>>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> f2py-users mailing list >>>> f2py-users-Y4l6ocDipWCuvFJfX82//[email protected] >>>> http://cens.ioc.ee/mailman/listinfo/f2py-users >>>> >>> >>> >>> >>> -- >>> Benjamin D. Forbes >>> School of Physics >>> The University of Melbourne >>> Parkville, VIC 3010, Australia >>> >> >> >> >> -- >> Benjamin D. Forbes >> School of Physics >> The University of Melbourne >> Parkville, VIC 3010, Australia >> > > >