Alternatives to symlinking Code Aster pyd files

[Krande]

Comment:

As mentioned in https://github.com/conda-forge/code-aster-feedstock/issues/65.

Need to find an alternative to symlinking dlls. Symlinking requires administator privileges on windows and will not work on cf. I have asked Mathieu about it in issue https://gitlab.com/codeaster/src/-/issues/1#note_1929414100 To me it seems like we either make a patch with a rewrite of the pybind11 module definitions into separate pyd's or we try to see if static linking and making copies fixes things. I dont have much experience with static linking, so this might take me some time to figure out.

bibcxx.dll <- libaster.pyd
bibc.dll <- aster.pyd,aster_core.pyd, aster_fonctions.pyd, med_aster.pyd

I am thinking I'll try to remove the following from the bibc.dll compilation and compile them separately to create standalone pyd's:

- aster_module.c -> aster.pyd
- aster_core_module.c -> aster_core.pyd
- aster_fonctions_module.c -> aster_fonctions.pyd
- med_aster_module.c -> med_aster.pyd

@philbucher You mentioned in https://github.com/Jesusbill/code-aster-examples/issues/2 that you are well versed in pybind11 :) Do you have any suggestions to how we might rewrite the pybind11 module definitions in Code Aster in order to not have to use symlinking?

[philbucher]

hey, I encountered a similar issue but with regular python modules instead of dlls. Long story short, we decided to copy the files to avoid changing anything else. In the end this was the easier solution for us

TBH I am not sure if pybind extensions can be compiled into static libs, can they then even be loaded in python? I dont think so, according to the original author of pybind

[Krande]

Yeah, I did try to copy the files instead of symlinking. Unfortunately that resulted in the following error:

>>> from code_aster import CA
aster_core_module.c 174 : erreur lors de l'appel a la methode CoreOptions.get_option
SystemError: null argument to internal routine
SystemError: null argument to internal routine

Which at the moment I am not quite able to understand how to fix. If you have any ideas as to where I should look, feel free to share :) In the meantime, I'll just keep digging :)

[philbucher]

that error does not seem to be related to the symlinking, but rather C <-> python interface itself I would take a close look at this function, IIRC quite some magic happens there, perhaps sth does not work on win

[Krande]

Yes, it seems like PyObject_CallMethod( get_sh_params(), "get_option", "s", option ); returns null.

So maybe there is something wrong with the python <-> fortran communication? I have raised this issue here also in hopes of getting some tips.

PyObject *asterc_getopt( _IN char *option ) {
    /*
     * Interface Fortran/Python pour récupérer une option de la ligne de commande.
     * Retourne :
     *  iret = 0 : tout est ok
     *  iret > 0   erreur
     *      iret = 1 : longueur de valk insuffisante, valeur tronquée
     *      iret = 4 : option inexistante, type incorrect.
     */
    PyObject *res;

    res = PyObject_CallMethod( get_sh_params(), "get_option", "s", option );
    if ( !res )
        MYABORT( "erreur lors de l'appel a la methode CoreOptions.get_option" );

    return res;
}

I wonder if it is possible to define ASTER_WITHOUT_PYMOD and just copy the module definitions in separate .c files and compile each of the files into its own pyd file and link to bibc.dll..

[Krande]

Hey,

I managed to replace the pyd-dll symlinks with c++ code that loads the bibc/bibcxx dlls and returns the pybind11 module definitions. This seems to work just fine so far. The entrypoints are defined here: https://gitlab.com/krande/src/-/tree/win-support/msvc/c_entrypoints?ref_type=heads

I will close this issue for now. If I find something lurking that makes this a unacceptable I can re-open it.