On Thu, February 14, 2008 8:24 am, Garry Willgoose wrote: > Thanks for that. The docs suggest library dl is Unix only. Does that > mean this solution will not work on Windows? Windows is on my > implementation roadmap but I'm not quite there yet to test it.
I have no idea whether it will work on Windows or not. I would try though as there seems to be other ways than dl to find the needed flags as Lisandro pointed out. > I guess I am now thinking maybe I can assemble (using f2py) an > (aggregated) shared library on the fly from the individual module > shared libraries when I open my modelling environment. I could check > the aggregated library mod dates against all the .so files of the > components and only rebuild the aggregated library if there was a > newer component than the aggregated library. That appears to work > (and is fast) except for one behaviour of f2py. If I give f2py a list > of files that are ALL .so (i.e. no fortran files) then f2py quits > without actually doing anything, even if all the component shared > libraries all have perfectly fine pythons interfaces from previous > f2py builds. I can give it a trivial fortran file (module .. end > module) and it works fine. Note that f2py job is not really perform linking tasks. It is a useful feature that simplifies creating extensions modules, but please, don't complain if it cannot be used as a general linker:) > Why is that problem? I can envisage a user that just wants to use the > environment without writing any additional fortran modules (and thus > may not even have an installed fortran compiler) and if they screw up > mod dates on the files (by say a ftp from one machine to another ... > for instance on our cluster the compiler is only installed on one > machine and only binaries are moved around the cluster) then the > environment might want to reassemble (with f2py) the aggregated > library because it (erroneously) thinks there is a newer component > shared library. This will fail because f2py quits when asked to > process ONLY .so files. If I have a trivial fortran file to force > f2py then this forces users to have a fortran compiler on their > machine, even if they do not want to actually compile a new fortran > module component, simply because f2py will not operate unless it is > offered at least one fortran file. This is not a typical task for f2py. f2py is not a general purpose linker. It's amazing that f2py could even be used for such a task, so I don't think that the above demonstrates any bug of f2py. However, if you are worried about whether users have fortran compilers installed then can you assume that they have a C compiler installed? If so, then instead of trivial Fortran file try using the following trivial .pyf file: python module dummy interface subroutine dummyfunc() fortranname callstatement ; end subroutine dummyfunc end interface end python module dummy that should force f2py to build a shared library dummy.so with no Fortran dependencies. > Does this make sense or am I just being thick about this? Is there a > way of making f2py merge a number of existing shared libraries into a > single library without having to compile any fortran. I guess I could > just invoke the linker directly in the case where there are no > fortran files to compile but is nice being able to use distutils to > get away from platform dependencies. Hopefully the hint above works for you. Pearu _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion