Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linker improvements to transparently handle site-specific paths #7

Open
4 tasks
hiker opened this issue Jul 12, 2024 · 1 comment
Open
4 tasks

Linker improvements to transparently handle site-specific paths #7

hiker opened this issue Jul 12, 2024 · 1 comment
Assignees

Comments

@hiker
Copy link
Owner

hiker commented Jul 12, 2024

In order to better support different paths on different sites:

  • The linker base class should provide a dictionary that maps strings (which are 'standard' library names) to a list of linker flags. E.g.
    'xios' -> ["-L", "/bla/bla", "-l", "morebla"] 
    'netcdf' -> ['$(nf-config --flibs)', '($nc-config --libs)`]`,
    
  • An application than only specifies which libraries it needs to link with (and in what order), and the linker then adds the correct flags during the linking stage.
  • If a library is specified that is unknown, raise an error.
  • There must be function to add and remove libraries (and Fab as default would likely provide none? Or Maybe just say netcdf as an example, since this is reasonable portable). Site-specific scripts will want to modify the settings (e.g.
jasonjunweilyu added a commit that referenced this issue Jul 15, 2024
@lukehoffmann lukehoffmann self-assigned this Jul 23, 2024
@hiker
Copy link
Owner Author

hiker commented Sep 23, 2024

Looking at the PR, we had a misunderstanding - we need these flags as part of the linker (site- and compiler-specific), not the link step (which should be as independent from site/compiler as possible).

Here what I want to do when setting up a linker:

    gfortran = tr.get_tool(Category.LINKER, "linker-gfortran")
    gfortran.add_lib_flags("yaxt", ["-lyaxt", "-lyaxt_c"])
    gfortran.add_lib_flags("xios", ["-lxios"])
    gfortran.add_lib_flags("hdf5", ["-lhdf5"])
    gfortran.add_lib_flags("stdc++", ["-lstdc++"])

Now imagine that I need to add one common (e.g. spack-based) path (I know, it should all work out of the box, but other user's might have a different setup - on my laptop I have to add include path for the compiler. While this is different from the linker, you get the idea). ATM I would have to add the -L option for each library that I add, since I don't know what libraries the application will link with (e.g. it could just link with xios and not yaxt, or just hdf5 - but would need the same path for all these libs) - so in order for the linker to find each libs in whatever subset and order they are specified, each library would need to have the same path added. While this works (and it might be required if you have e.g. a more classical module setup, with each lib in a different directory), it is a lot more convenient to be able to write:

    gfortran = tr.get_tool(Category.LINKER, "linker-gfortran")
    gfortran.add_pre_flags(["-L", "/my/path/to/all/libs"]
    gfortran.add_lib_flags("yaxt", ["-lyaxt", "-lyaxt_c"])
    gfortran.add_lib_flags("xios", ["-lxios"])
    gfortran.add_lib_flags("hdf5", ["-lhdf5"])
    gfortran.add_post_flags(["-lstdc++"])      # Somewhat made up, but when we link with gfortran, we throw in the C++ libs

Even if the user should link with no libs, these flags should be added (seems unlikely that you have nothing to link in tbh :) ), but I can't see that adding these flags can hurt. Even if you are not using c++ and therefore don't need to link with it, it can't hurt (except for a few seconds linking time).

Hope that's clearer now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants