[f2py] Compiling/linking the Fortran source files manually

Pearu Peterson pearu.peterson at gmail.com
Tue Apr 26 13:12:12 EEST 2011 

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<bdforbes at gmail.com>  wrote:
>> It works straight away on Linux.
>>
>> On Tue, Apr 26, 2011 at 7:29 PM, Ben Forbes<bdforbes at gmail.com>  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
>>> <pearu.peterson at gmail.com>  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
>>>>> <pearu.peterson at gmail.com>    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
>>>>>>> <pearu.peterson at gmail.com>      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<bdforbes at gmail.com>        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
>>>>>>>>>> <pearu.peterson at gmail.com>        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 at cens.ioc.ee
>>>>>>>>>>> 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 at cens.ioc.ee
>>>>>>>> http://cens.ioc.ee/mailman/listinfo/f2py-users
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> f2py-users mailing list
>>>>>> f2py-users at cens.ioc.ee
>>>>>> http://cens.ioc.ee/mailman/listinfo/f2py-users
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> f2py-users mailing list
>>>> f2py-users at cens.ioc.ee
>>>> 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
>>
>
>
>

More information about the f2py-users mailing list