Hello, May I ask, what is the rationale for the changes for the swithches in the 'compaq_visual_fortran_compiler' class between CVS version 1.80 and today's head. The old ones (working for me were) (line 1527): switches = ' /nologo /MD /W1 /iface:cref /iface=nomixed_str_len_arg ' in current head I find (not working for me) (line 1537-1539): switches = ' /nologo /nodebug /MD /WX '\ ' /iface=(cref,nomixed_str_len_arg) /names:lowercase '\ ' /assume:underscore /threads ' shouldn't /nodebug only be set if not in debug mode? The main problems I have with the /iface and /names settings that break some code by me, ie my carefully compiled Atlas/lapack libraries under WinXP. Kind regards Berthold Höllmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel@gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark@germanlloyd.org will be replaced by shortmark@gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.
On Tue, 28 Oct 2003, [iso-8859-15] Berthold Höllmann wrote:
Hello,
May I ask, what is the rationale for the changes for the swithches in the 'compaq_visual_fortran_compiler' class between CVS version 1.80 and today's head. The old ones (working for me were) (line 1527):
switches = ' /nologo /MD /W1 /iface:cref /iface=nomixed_str_len_arg '
in current head I find (not working for me) (line 1537-1539):
switches = ' /nologo /nodebug /MD /WX '\ ' /iface=(cref,nomixed_str_len_arg) /names:lowercase '\ ' /assume:underscore /threads '
shouldn't /nodebug only be set if not in debug mode?
I agree.
The main problems I have with the /iface and /names settings that break some code by me, ie my carefully compiled Atlas/lapack libraries under WinXP.
The rationale is that all supported compilers should behave in the same way, that is, lower cases and append underscore to fortran symbols. Different compilers may behave differently in this respect and with additional switches one can "tune" a compiler as needed. Earlier compaq_visual_fortran_compiler did not follow this convention and hence the changes. Sorry that it broke some of your codes and I hope it is not too much trouble for you to fix them. Pearu
Pearu Peterson <pearu@scipy.org> writes:
On Tue, 28 Oct 2003, [iso-8859-15] Berthold Höllmann wrote:
Hello,
May I ask, what is the rationale for the changes for the swithches in the 'compaq_visual_fortran_compiler' class between CVS version 1.80 and today's head. The old ones (working for me were) (line 1527):
switches = ' /nologo /MD /W1 /iface:cref /iface=nomixed_str_len_arg '
in current head I find (not working for me) (line 1537-1539):
switches = ' /nologo /nodebug /MD /WX '\ ' /iface=(cref,nomixed_str_len_arg) /names:lowercase '\ ' /assume:underscore /threads '
shouldn't /nodebug only be set if not in debug mode?
I agree.
The main problems I have with the /iface and /names settings that break some code by me, ie my carefully compiled Atlas/lapack libraries under WinXP.
The rationale is that all supported compilers should behave in the same way, that is, lower cases and append underscore to fortran symbols. Different compilers may behave differently in this respect and with additional switches one can "tune" a compiler as needed. Earlier compaq_visual_fortran_compiler did not follow this convention and hence the changes. Sorry that it broke some of your codes and I hope it is not too much trouble for you to fix them.
But do you do with Third party delivered libraries you want to wrap. We have a set of huge libraries where we can't compile of our own. From time to time we need/have fortran wrapper around these libraries that then need to be wrapped for python. These Fortran wrapper are only needed for the Python wrapper and as such are compiled as library unsing distutils. Would it be possible to provide a mechanism to allow user defined settings for the "switches" to make the libraries work? Kind regards Berthold Höllmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel@gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark@germanlloyd.org will be replaced by shortmark@gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.
On Wed, 29 Oct 2003, [iso-8859-15] Berthold Höllmann wrote:
The rationale is that all supported compilers should behave in the same way, that is, lower cases and append underscore to fortran symbols. Different compilers may behave differently in this respect and with additional switches one can "tune" a compiler as needed. Earlier compaq_visual_fortran_compiler did not follow this convention and hence the changes. Sorry that it broke some of your codes and I hope it is not too much trouble for you to fix them.
But do you do with Third party delivered libraries you want to wrap. We have a set of huge libraries where we can't compile of our own. From time to time we need/have fortran wrapper around these libraries that then need to be wrapped for python. These Fortran wrapper are only needed for the Python wrapper and as such are compiled as library unsing distutils. Would it be possible to provide a mechanism to allow user defined settings for the "switches" to make the libraries work?
Could you give a more detailed example of the fortran wrapper and how do you wrap it to Python? If these wrappers can be modified e.g. by inserting f2py directives, then `fortranname` .pyf file command might be what you need. Pearu
Pearu Peterson <pearu@scipy.org> writes:
On Wed, 29 Oct 2003, [iso-8859-15] Berthold Höllmann wrote:
The rationale is that all supported compilers should behave in the same way, that is, lower cases and append underscore to fortran symbols. Different compilers may behave differently in this respect and with additional switches one can "tune" a compiler as needed. Earlier compaq_visual_fortran_compiler did not follow this convention and hence the changes. Sorry that it broke some of your codes and I hope it is not too much trouble for you to fix them.
But do you do with Third party delivered libraries you want to wrap. We have a set of huge libraries where we can't compile of our own. From time to time we need/have fortran wrapper around these libraries that then need to be wrapped for python. These Fortran wrapper are only needed for the Python wrapper and as such are compiled as library unsing distutils. Would it be possible to provide a mechanism to allow user defined settings for the "switches" to make the libraries work?
Could you give a more detailed example of the fortran wrapper and how do you wrap it to Python? If these wrappers can be modified e.g. by inserting f2py directives, then `fortranname` .pyf file command might be what you need.
Now i have a binary Fortran library named 'provided'. 'provided' provides a function 'subroutine foo()' which leads to a symol '_FOO@0' in the library. Now i want to write a function that makes intensive use of 'foo', so I write a Fortran routine 'subroutine usefoo()' that is specific to python ant I wrap it unsing f2py. Because 'usefoo' is only usefull for my Python extension library I include it's sourcecode in my Python Project and build it as 'fortran_libraries' using scipy distutils. With the switches' settings as they are now this does not work, because the linker looks for '_foo_' instead of '_FOO' or '_FOO@0'. Kind regards Berthold Höllmann -- Germanischer Lloyd AG CAE Development Vorsetzen 35 20459 Hamburg Phone: +49(0)40 36149-7374 Fax: +49(0)40 36149-7320 e-mail: hoel@gl-group.com Internet: http://www.gl-group.com **************************************************** Please notice: We would like to inform you that the e-mail address of Germanischer Lloyd as well as our internet address had been changed to gl-group.com with effect from 1st March 2003. This means that the previous address shortmark@germanlloyd.org will be replaced by shortmark@gl-group.com. From now on the GL homepage can be accessed at the address 'http://www.gl-group.com'. The old addresses remain valid for a transitional period. **************************************************** This e-mail contains confidential information for the exclusive attention of the intended addressee. Any access of third parties to this e-mail is unauthorised. Any use of this e-mail by unintended recipients such as copying, distribution, disclosure etc. is prohibited and may be unlawful. When addressed to our clients the content of this e-mail is subject to the General Terms and Conditions of GL's Group of Companies applicable at the date of this e-mail. GL's Group of Companies does not warrant and/or guarantee that this message at the moment of receipt is authentic, correct and its communication free of errors, interruption etc.
On Wed, 29 Oct 2003, [iso-8859-15] Berthold Höllmann wrote:
Pearu Peterson <pearu@scipy.org> writes:
Could you give a more detailed example of the fortran wrapper and how do you wrap it to Python? If these wrappers can be modified e.g. by inserting f2py directives, then `fortranname` .pyf file command might be what you need.
Now i have a binary Fortran library named 'provided'. 'provided' provides a function 'subroutine foo()' which leads to a symol '_FOO@0' in the library. Now i want to write a function that makes intensive use of 'foo', so I write a Fortran routine 'subroutine usefoo()' that is specific to python ant I wrap it unsing f2py. Because 'usefoo' is only usefull for my Python extension library I include it's sourcecode in my Python Project and build it as 'fortran_libraries' using scipy distutils. With the switches' settings as they are now this does not work, because the linker looks for '_foo_' instead of '_FOO' or '_FOO@0'.
Thanks for the explanation. So, you must be also using -DUPPERCASE_FORTRAN and -DPREPEND_FORTRAN cpp options. In fact, there are two possible ways for resolving Fortran symbols in f2py generated modules: + One is to uses compiler options to force certian convention that I explained earlier. + And the other is to use certain combinations of the CPP variables UPPERCASE_FORTRAN, PREPEND_FORTRAN, NO_APPEND_FORTRAN. In scipy_distutils we are using the first way because of two reasons: (i) this avoids issues with symbols containing characters like @ or ! that certain Fortran compilers may add to the initial names; namely, these characters in names will cause C compiler to complain as they are not allowed characters for C names. (ii) we haven't worked out a way how to define CPP macros for a C compiler depending on the Fortran compiler, and all that within the framework of distutils. But to resolve your case, there should be a way to define Fortran compiler options for scipy_distutils, but this feature is not implemented yet because we haven't needed it earlier. Meanwhile, you can use the following workaround in the setup.py file: from scipy_distutils.command import build_flib class my_fortran_compiler(build_flib.compaq_visual_fortran_compiler): def __init__(self, fc=None, f90c=None, verbose=0): build_flib.compaq_visual_fortran_compiler.__init__(self,fc,f90c,verbose) s = self.f77_switches s = s.replace('/names:lowercase','') s = s.replace('/assume:underscore','') # ... self.f77_switches = s # similarly can be self.f90_switches fixed. i = build_flib.all_compilers.index(build_flib.compaq_visual_fortran_compiler) build_flib.all_compilers[i] = my_fortran_compiler Note that I have not tested this code but it should work after fixing any possible typos that I might have been made here. Pearu
participants (2)
-
Berthold Höllmann -
Pearu Peterson