modules-interest — Modules discussions — NEW HOME: https://lists.hpsf.io/g/modules-interest

[Modules] Hook API

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Hi all,

With the upcoming Modules 5.7 release, sites will get a new, stable way to
run their own code around modulefile and modulerc evaluation, without
having to reach into modulecmd.tcl internals.

Until now, running site-specific code before or after an evaluation meant
either using the Tcl trace command on an internal procedure like
execute-modulefile, or renaming and wrapping an internal procedure
outright. Both techniques work, but they bind site configuration to
implementation details that can change from one Modules version to the next
— meaning sites relying on them have had to re-check their siteconfig
against the internal code on every upgrade.

5.7 will introduce a new add-hook <event> <procedure> siteconfig command
instead. It lets you register one or more procedures on a fixed, documented
set of events, each with a stable, versioned argument contract:
  - before-modulefile-eval / after-modulefile-eval
  - before-modulerc-eval / after-modulerc-eval

Multiple procedures can be registered on the same event and will run in
registration order. A hook procedure that raises an error gets reported,
but won't abort the running module command or block the other procedures
registered on that event — these hooks fire on nearly every invocation, so
a mistake in one shouldn't lock out the tool site-wide.

The existing trace/rename techniques aren't going away — they remain
available as a lower-level fallback for anything not (yet) covered by a
hook event, and we expect to add further events over time as real use cases
come up.

A couple of things worth looking at once 5.7 is out:

  - The Hooks section of the module(1) man page documents add-hook and all
four events, with examples.
  - The MIGRATING guide has a short write-up of the feature:
https://modules.readthedocs.io/en/latest/MIGRATING.html#hook-api
  - A new cookbook recipe shows a realistic use case: syncing an
application directory from a network share to local disk on a module's
first load, using a before-modulefile-eval hook:
https://modules.readthedocs.io/en/latest/cookbook/sync-remote-appdir.html
  - If you'd like to contribute a new hook event yourself, there's now a
dedicated contributor guide walking through what needs to change (core
code, docs, testsuite):
https://modules.readthedocs.io/en/latest/devel/add-new-hook-event.html

As always, feedback and questions are welcome here on the list.

Cheers,
Xavier


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#45): https://lists.hpsf.io/g/modules-interest/message/45
Mute This Topic: https://lists.hpsf.io/mt/120640069/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Prevent modulefile search from looking at all files in directory

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Hello Everyone,

I am digging out this old thread today to tell you I was able to put in
place an optimization when looking for an exact "name/version" module (if
"name" directory does not include sub-directories to resolve highest module
version).

In such case, there is no more validation of every sibling modulefiles.
Only the targeted module and the highest module are resolved.

A substantial performance improvement is observed when "name" directory
contains numerous version files (100+). A "load3" bench test case has been
added to the script/mb utility. This test case create 500 version files and
on my laptop I observe a performance improvement of 36%. I am quite sure
this improvement is bigger when modulefiles are stored on a network shared
filesystem rather than a local SSD.

The performance improvement highlights made for next version (5.7.0) has
been updated to cover this additional enhancement:
https://modules.readthedocs.io/en/latest/MIGRATING.html#improving-evaluation-performances


Best regards,
Xavier

Le mer. 22 janv. 2025 à 08:32, Xavier Delaruelle <
xav...@gm...> a écrit :

> Thanks Eric for the benchmark information.
>
> Working on optimizing direct access to version file should improve the
> performance obtained. I need to rethink strategy of analyzing existing
> files.
>
> Best regards,
> Xavier
>
> Le mar. 21 janv. 2025 à 23:55, Miller, Eric via Modules-interest
> <mod...@li...> a écrit :
> >
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> > I attempted to optimize our use case by removing the non-modulefiles
> from the equation, so here are some benchmark results on my system.
> >
> > $ ./timeit.sh
> > 3.2.10 large: 0.080s
> > 3.2.10 small: 0.064s
> > 5.5.0 large, no cache: 0.583s (7.2x longer)
> > 5.5.0 large, with cache: 1.985s (24x longer)
> > 5.5.0 small, no cache: 0.348s (5.4x longer)
> > 5.5.0 small, with cache: 1.895s (30x longer)
> >
> > Test details:
> > ~10000 modulefiles spanning 720 packages.
> > The .modulecache file is 7.3MB in size.
> > The "large" package has 432 modulefile versions.
> > The "small" package has 32 modulefile versions.
> > "modulecmd load package/x.y.z" is run 10 times (where x.y.z is a fully
> resolved version)
> >
> > Again, this is a modulefile-only tree, so I don't believe any of the
> proposals discussed so far would have any impact.
> >
> > We load lots of modulefiles, so these increases in load times add up.
> >
> > Thanks,
> > Eric
> >
> > -----Original Message-----
> > From: Xavier Delaruelle <xav...@gm...>
> > Sent: Saturday, January 18, 2025 6:08 AM
> > To: Environment Modules usage and discussion. <
> mod...@li...>
> > Subject: Re: [Modules] Prevent modulefile search from looking at all
> files in directory
> >
> > Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
> >
> >
> > Hello Martin,
> >
> > Thanks for the use case description. This feature will take it into
> account.
> >
> > The idea is to update the "findModulesFromDirsAndFiles" procedure and
> check for each element found in a directory if it should be taken into
> account or ignored. The result of this procedure is used to determine the
> list of available modules, which is used by all commands to find/list
> modules.
> >
> > I will update the ticket issue with the information provided.
> >
> > Best regards,
> > Xavier
> >
> > Le ven. 17 janv. 2025 à 17:01, Bloecker, Martin <
> Mar...@am...> a écrit :
> > >
> > > Hello Xavier,
> > >
> > > from your summary below it is not clear to me if your proposed
> 'modulepath-only' and 'modulepath-ignore' commands would solely work in
> modifying the modulepath or if they would work on a per file level (e.g. to
> exclude certain file types from being considered modulefiles).
> > >
> > > The use case I was hoping to address with the new feature is the
> following: For the sake of modularity we have some files in module
> directories that are e.g. read by modulefiles but which are not valid
> modulefiles themselves. Currently these are hidden files (i.e. their name
> starting with a dot, e.g. '.some_function.tcl') so that the module command
> does not 'see' them.
> > >
> > > When managing the module directory tree these hidden files sometimes
> cause confusion. If we were able to define a modulefile name filter (e.g.
> ignore all *.tcl files) we could make such files regular files w/o any
> impact on the traversing of the modulepath. Hence the idea of using the
> gitignore syntax as this would enable ignoring both (classes of) files as
> well as directories. Or explicitly including them via negation.
> > >
> > > Best Regards,
> > >
> > > Martin
> > >
> > > -----Original Message-----
> > > From: Xavier Delaruelle <xav...@gm...>
> > > Sent: Freitag, 17. Januar 2025 07:52
> > > To: Environment Modules usage and discussion.
> > > <mod...@li...>
> > > Subject: Re: [Modules] Prevent modulefile search from looking at all
> > > files in directory
> > >
> > > 🛑 ACHTUNG: Diese E-Mail stammt nicht von AMTC oder Tekscend
> Photomask. Vor dem Öffnen von Links oder Anhängen bitte Absender und
> Kontext sorgfältig prüfen. // This email does not originate from AMTC or
> Tekscend Photomask. Please consider the sender and context before opening
> links or attachments.
> > >
> > > Many thanks Martin helping to craft this new feature.
> > >
> > > This is how I see it currently:
> > > * multiple pattern may be specified on one command and command may be
> > > defined several times
> > > * this will give a list of all pattern to ignore (or only include)
> > > * as soon as a "modulepath-only" command is set, "modulepath-ignore"
> > > patterns are all ignored
> > > * patterns are prefixed by the location of the modulerc where they are
> defined
> > >      for instance "modulepath-ignore 1*" in "modpath/foo/.modulerc"
> > > produces the "modpath/foo/1*" ignore pattern
> > >
> > > I am quite in line with your approach of basing things on something
> > > already existing and well used/designed. I have also to mix this motto
> > > with having a performant solution (important to have a new command in
> > > .modulerc file to avoid having to check for the existence of an
> > > additional file in every walked down directory) and making a
> > > progressive implementation: something simpler (just glob pattern for
> > > instance) implemented first, then later refined to get full
> gitignore-like syntax capability.
> > >
> > > I have looked to the negate pattern. From my understanding, it is
> there to undo an ignore pattern. So another command will be needed to
> express the *include only* list.
> > >
> > > Many thanks again, that's truly help to design this new feature.
> > >
> > > Regards,
> > > Xavier
> > >
> > > Le mer. 15 janv. 2025 à 11:19, Bloecker, Martin <
> Mar...@am...> a écrit :
> > > >
> > > > Xavier, Paul,
> > > >
> > > > I understand the reasoning behind implementing this via the
> .modulerc file. There are a couple of questions that need to be thought of
> when going down that route:
> > > >   1. Can multiple search and/or ignore patterns be specified?
> > > >     - In a single command?
> > > >     - Via multiple subsequent commands?
> > > >   2. Can search and ignore patterns be mixed? What takes precedence?
> > > >   3. In case of multiple search and/or ignore patterns: Can other
> module commands be used between them? What would be the impact on
> implementation and module behavior?
> > > >
> > > > Apart from answering these questions I think it is still worthwhile
> considering the gitignore format to specify search and ignore patterns. I'm
> pretty sure the git developers have well though about any conceivable
> filtering requirement 😉. Namely there is a syntax to negate patterns which
> would allow for a single .modulerc command to cover both inclusion (i.e.
> search) and exclusion (i.e. ignore) patterns.
> > > >
> > > > Regards,
> > > >
> > > > Martin
> > > > -----Original Message-----
> > > > From: Xavier Delaruelle <xav...@gm...>
> > > > Sent: Mittwoch, 15. Januar 2025 07:43
> > > > To: Environment Modules usage and discussion.
> > > > <mod...@li...>
> > > > Subject: Re: [Modules] Prevent modulefile search from looking at all
> > > > files in directory
> > > >
> > > > 🛑 ACHTUNG: Diese E-Mail stammt nicht von AMTC oder Tekscend
> Photomask. Vor dem Öffnen von Links oder Anhängen bitte Absender und
> Kontext sorgfältig prüfen. // This email does not originate from AMTC or
> Tekscend Photomask. Please consider the sender and context before opening
> links or attachments.
> > > >
> > > > Many thanks Martin and Paul. That's very good idea to have a
> mechanism to define patterns to ignore when walking down a modulepath tree.
> > > >
> > > > I also prefer to have this implemented through new commands in
> .modulerc file.
> > > >
> > > > In addition to a command to ignore pattern, I feel like a command
> that defines patterns to only take into account may be useful, especially
> in a case like this one where modulefiles are a few files within a large
> amount of other kind of files.
> > > >
> > > > I have added a comment to the github issue
> > > > (https://github.com/envmodules/modules/issues/561) to specify how
> things could be implemented. Feel free to comment.
> > > >
> > > > Regards,
> > > > Xavier
> > > >
> > > > Le mar. 14 janv. 2025 à 15:50, Paul Markfort <pau...@gm...>
> a écrit :
> > > > >
> > > > > I would say, just add this functionality to .modulerc  (why create
> another file?) - it is already read first.
> > > > > And - yes, restriction to an extension (or set of extensions)
> should not be the default setting (just an option that can be turned on).
> > > > >
> > > > >
> > > > > On 2025-01-14 2:59 AM, Bloecker, Martin wrote:
> > > > > > All,
> > > > > >
> > > > > > following the discussion below one thought crossed my mind:
> Exclusion of certain (module)files from reading/processing could be done in
> much the same way as git is doing with .gitignore i.e. via a (to be
> implemented) .modulesignore file. From my perspective this approach would
> have several benefits:
> > > > > >
> > > > > > 1. No change in behavior for existing installations that don't
> require the new functionality.
> > > > > > 2. Existing installations/modulefile trees can easily be
> retrofitted by adding .modulesignore file(s).  Neither changes in
> modulefiles nor other modifications to existing files/directories should be
> required.
> > > > > > 3. Assuming a similar function set as the .gitignore file, using
> .modulesignore would enable
> > > > > >       - Excluding complete subdirectory trees from further
> processing (e.g. enable SW installations in the same tree as the respective
> modulefiles).
> > > > > >       - Restrict processing to certain file types (e.g. only
> '*.modfl' files).
> > > > > >       - Etc.
> > > > > >
> > > > > > I would assume that such a .modulesignore file would need to be
> the very first file being processed in every directory (i.e. right before
> the .modulerc file).
> > > > > >
> > > > > > Would this be a feasible option?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Martin
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Xavier Delaruelle <xav...@gm...>
> > > > > > Sent: Dienstag, 14. Januar 2025 07:41
> > > > > > To: Environment Modules usage and discussion.
> > > > > > <mod...@li...>
> > > > > > Subject: Re: [Modules] Prevent modulefile search from looking at
> > > > > > all files in directory
> > > > > >
> > > > > > 🛑 ACHTUNG: Diese E-Mail stammt nicht von AMTC oder Tekscend
> Photomask. Vor dem Öffnen von Links oder Anhängen bitte Absender und
> Kontext sorgfältig prüfen. // This email does not originate from AMTC or
> Tekscend Photomask. Please consider the sender and context before opening
> links or attachments.
> > > > > >
> > > > > > Hello Eric,
> > > > > >
> > > > > > Le lun. 13 janv. 2025 à 19:48, Miller, Eric via Modules-interest
> <mod...@li...> a écrit :
> > > > > >> The symlink approach requires modifying files that use the
> $ModulesCurrentModulefile variable.
> > > > > >
> > > > > > The following Tcl commands will help to get back the real path:
> > > > > > [file normalize [file readlink $ModulesCurrentModulefile]]
> > > > > >
> > > > > >> For testing purposes I just replaced the variable with the full
> path to the original file.
> > > > > >>
> > > > > >> I tested the modulefile-only tree by loading a package having
> 435 versions and module load package/1.2.3, which resolves to an actual
> version file.
> > > > > >> 3.2.10: 70ms
> > > > > >> 5.5:  570ms
> > > > > >> OS disk caching (i.e. repeated runs) knocks that down to 50ms
> and 150ms respectively.
> > > > > >>
> > > > > >> This is better than using the release repository for the module
> path, but still too slow to justify switching from 3.2.10.
> > > > > >
> > > > > > I think introducing an option to avoid looking at adjacent files
> would be interesting for your setup.
> > > > > >
> > > > > > I have thought about Paul's suggestion on file extension: as it
> would help with non-modulefiles I think it will not solve the issue in case
> of large number of adjacent version files.
> > > > > >
> > > > > > I have created an issue to track this feature request:
> > > > > > https://github.com/envmodules/modules/issues/561
> > > > > >
> > > > > > I would be glad to get some sponsoring to work on this. You can
> contact me directly to exchange about that.
> > > > > >
> > > > > > Regards,
> > > > > > Xavier
> > > > > >
> > > > > >> The modulecache file is 7.3 MB and loads take ~220ms,
> regardless of OS caching.
> > > > > >> For packages with a small number of versions, using the cache
> file is much slower.
> > > > > >>
> > > > > >> Eric
> > > > > >>
> > > > > >> -----Original Message-----
> > > > > >> From: Paul Markfort <pau...@gm...>
> > > > > >> Sent: Monday, January 13, 2025 10:13 AM
> > > > > >> To: mod...@li...
> > > > > >> Subject: Re: [Modules] Prevent modulefile search from looking
> > > > > >> at all files in directory
> > > > > >>
> > > > > >> Caution: This message originated from an External Source. Use
> proper caution when opening attachments, clicking links, or responding.
> > > > > >>
> > > > > >>
> > > > > >> First Make sure you read this (if you haven't already):
> > > > > >> https://modules.readthedocs.io/en/stable/modulefile.html#locati
> > > > > >> ng
> > > > > >> -m
> > > > > >> odu
> > > > > >> lefiles
> > > > > >>
> > > > > >> An option you might try is to make a module tree that is simply
> populated with links to the actual module files.  And point MODULEPATH to
> that tree.  If that tree were structured exactly the same as your current
> tree (but only containing the modulefiles); the modulefiles would not have
> to be rewritten.
> > > > > >>
> > > > > >>
> > > > > >> I suspect, if modules could be told to restrict modulefiles to
> a particular file extension (what is the extension used for the windows
> version of modules?), the processing would speed up considerably (as it
> would not have to open every file to check if it is a module file). I
> should point out this is NOT a current feature - just asking if such an
> OPTIONAL feature would even be useful.
> > > > > >>
> > > > > >> Assuming that extension were .modfl  (It should probably be
> different),  You would not have to change the name of the modulefile, just
> add the extension to the name (the extension wouldn't be needed when
> referencing the file - as it would be assumed).
> > > > > >>
> > > > > >> So the module file would be:
> > > > > >> /release_path/package_name/version_directory/modulefile.modfl
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> On 2025-01-13 10:47 AM, Miller, Eric via Modules-interest wrote:
> > > > > >>> [AMD Official Use Only - AMD Internal Distribution Only]
> > > > > >>>
> > > > > >>> Hi Xavier-
> > > > > >>>
> > > > > >>> Thank you for the quick reply.
> > > > > >>>
> > > > > >>> You are correct, we do see poor performance when running
> "module avail" under 3.2.10.
> > > > > >>> However, we never use that command.  Perhaps we would if the
> performance was better.
> > > > > >>>
> > > > > >>> It is not a hardware issue, but rather a scaling issue.  We
> have thousands of software packages with millions of non-modulefile files
> across the version directories.
> > > > > >>> All our packages are structured as:
> > > > > >>> /release_path/package_name/version_directory/modulefile
> > > > > >>>
> > > > > >>> For now we are specifying the full path just as you
> recommended in the second email, but this approach is just a short term fix.
> > > > > >>>
> > > > > >>> Another workaround we have tried is isolating the modulefiles
> from the release repository into a standalone module_path.  However, this
> requires us to rewrite all our existing modulefiles (~10k).
> > > > > >>> I'll continue to do experiments in this area.  Perhaps we can
> automate the conversion and add it to our release process.
> > > > > >>>
> > > > > >>> The cache currently has 2 issues that prevent us from using it
> with our current setup:
> > > > > >>>     1. Creating the cache is slow and uses lots of memory.  I
> killed cachebuild after running for 2.5hrs and using 81GB of memory on
> modern enterprise hardware.
> > > > > >>>     2. Even if the cache is created, using it is still
> somewhat slow.  Removing the module-invalid commands in the cache file
> helps, but is still slower than the search behavior in 3.2.10.
> > > > > >>>
> > > > > >>> I would ask for the following enhancements to bring the search
> performance back to parity with version 3 (or even improve on it):
> > > > > >>>     1. Grant the ability to tune the modulefile search so it
> does not inspect all files in a version directory.
> > > > > >>>     2. If there is an exact path match to the search
> specifier, use it without searching or inspecting the modulefiles.
> > > > > >>>     3. Improve the cache file search performance and memory
> usage (i.e. do not load the entire cache into memory).  This can be tricky.
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>> Eric Miller
> > > > > >>>
> > > > > >>> -----Original Message-----
> > > > > >>> From: Xavier Delaruelle <xav...@gm...>
> > > > > >>> Sent: Sunday, January 12, 2025 11:58 PM
> > > > > >>> To: Environment Modules usage and discussion.
> > > > > >>> <mod...@li...>
> > > > > >>> Subject: Re: [Modules] Prevent modulefile search from looking
> > > > > >>> at all files in directory
> > > > > >>>
> > > > > >>> Caution: This message originated from an External Source. Use
> proper caution when opening attachments, clicking links, or responding.
> > > > > >>>
> > > > > >>>
> > > > > >>> I just remind of an alternative way which is to refer to the
> module by its full path name:
> > > > > >>>
> > > > > >>> module load /path/to/ModulePath/MyModule/1.0/modulefile
> > > > > >>>
> > > > > >>> This way, no other files will be scanned/evaluated.
> > > > > >>>
> > > > > >>> This solution may help you to find the speed you expect.
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>> Xavier
> > > > > >>>
> > > > > >>> Le dim. 12 janv. 2025 à 20:40, Xavier Delaruelle <
> xav...@gm...> a écrit :
> > > > > >>>>
> > > > > >>>> Hello Eric,
> > > > > >>>>
> > > > > >>>> Best solution I can think of is using module cache.
> > > > > >>>>
> > > > > >>>> It is a bit slower but it should not be noticeable. If it
> > > > > >>>> does, I would suggest to look at the performance of the
> > > > > >>>> underlying storage system. If there is no issue with the
> > > > > >>>> storage system, I would be happy to get some debugging output
> in --timer mode.
> > > > > >>>>
> > > > > >>>> With large number of non-modulefiles in modulepaths, load is
> > > > > >>>> slower on newer version of Modules than 3.2 due to collecting
> > > > > >>>> all module symbols that applied to loading module. Even if
> > > > > >>>> load is efficient with this kind of setup on version 3.2, bad
> > > > > >>>> performance should be observed on "module avail".
> > > > > >>>>
> > > > > >>>> Regards,
> > > > > >>>> Xavier
> > > > > >>>>
> > > > > >>>> Le ven. 10 janv. 2025 à 16:59, Miller, Eric via
> > > > > >>>> Modules-interest <mod...@li...> a
> écrit :
> > > > > >>>>>
> > > > > >>>>> [AMD Official Use Only - AMD Internal Distribution Only]
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> My question:  Is there a way to optimize the modulefile
> search algorithm for cases where the directory contains many files that are
> NOT modulefiles?
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Background:
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Given a directory structure like:
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> ModulePath/MyModule/1.0/
> > > > > >>>>>
> > > > > >>>>> ModulePath/MyModule/1.1/
> > > > > >>>>>
> > > > > >>>>> ...
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> And given that each version directory contains one file
> named "modulefile" at the root of the directory and also contains a large
> number of other subdirectories and files.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> The command: "module load MyModule/1.0" will be very slow.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> The root cause appears to be that the modulefile search
> algorithm stats and reads every file in each of the ModulePath/MyModule/*
> directories.
> > > > > >>>>>
> > > > > >>>>> Going back to modulecmd 3.2.10 we do not see this issue.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> I've tried setting MODULES_MCOOKIE_CHECK=eval, but that
> caused errors when the loader encountered non-modulefile files.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> I've also tried using the cachebuild command, and while it
> helps, it is still slower than 3.2.10.
> > > > > >>>>>
> > > > > >>>>> The cachefile also appears to be tied to that specific
> version of modulecmd due to the header: #%Module5.5.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> Thanks!
> > > > > >>>>>
> > > > > >>>>> Eric Miller
> > > > > >>>>>
> > > > > >>>>> _______________________________________________
> > > > > >>>>> Modules-interest mailing list
> > > > > >>>>> Mod...@li...
> > > > > >>>>> https://lists.sourceforge.net/lists/listinfo/modules-interes
> > > > > >>>>> t
> > > > > >>>
> > > > > >>>
> > > > > >>> _______________________________________________
> > > > > >>> Modules-interest mailing list
> > > > > >>> Mod...@li...
> > > > > >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > > >>>
> > > > > >>> _______________________________________________
> > > > > >>> Modules-interest mailing list
> > > > > >>> Mod...@li...
> > > > > >>> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > > >>>
> > > > > >>
> > > > > >> --
> > > > > >> --------------------------------------------------------
> > > > > >> The views and opinions expressed above are strictly those of
> the author(s).  The content of this message has not been reviewed nor
> approved by any entity whatsoever.
> > > > > >> --------------------------------------------------------
> > > > > >> Paul FM         Info: http://paulfm.com/~paulfm/
> > > > > >> --------------------------------------------------------
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Modules-interest mailing list
> > > > > >> Mod...@li...
> > > > > >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> Modules-interest mailing list
> > > > > >> Mod...@li...
> > > > > >> https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Modules-interest mailing list
> > > > > > Mod...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > > >
> > > > > > _______________________________________________
> > > > > > Modules-interest mailing list
> > > > > > Mod...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > > > >
> > > > >
> > > > > --
> > > > > --------------------------------------------------------
> > > > > The views and opinions expressed above are strictly those of the
> > > > > author(s).  The content of this message has not been reviewed nor
> > > > > approved by any entity whatsoever.
> > > > > --------------------------------------------------------
> > > > > Paul FM         Info: http://paulfm.com/~paulfm/
> > > > > --------------------------------------------------------
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Modules-interest mailing list
> > > > > Mod...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > >
> > > >
> > > > _______________________________________________
> > > > Modules-interest mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > > >
> > > > _______________________________________________
> > > > Modules-interest mailing list
> > > > Mod...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
> > >
> > > _______________________________________________
> > > Modules-interest mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> > >
> > > _______________________________________________
> > > Modules-interest mailing list
> > > Mod...@li...
> > > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
> >
> > _______________________________________________
> > Modules-interest mailing list
> > Mod...@li...
> > https://lists.sourceforge.net/lists/listinfo/modules-interest
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#44): https://lists.hpsf.io/g/modules-interest/message/44
Mute This Topic: https://lists.hpsf.io/mt/120531310/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] More Pythonic initialization for Modules

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

Modules initialization script for Python has been renamed "env_modules.py"
and new installation options
--enable-set-pythonpath/--enable-append-pythonpath have been introduced to
provide a better "Pythonic" way to initialize the "module" Python function.

With --enable-set-pythonpath (enabled by default), PYTHONPATH is defined
when initializing Modules in the shell: "init" directory is added to this
variable.

With this change, it is now possible to initialize the "module" Python
function this way:

from env_modules import module

Note that a compatibility link "python.py" is created over "env_modules.py"
to maintain compatibility.

Many thanks to Byron Boulton for his contribution on this new feature.

Regards,
Xavier


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#43): https://lists.hpsf.io/g/modules-interest/message/43
Mute This Topic: https://lists.hpsf.io/mt/120294603/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Next Technical Steering Committee (TSC) meeting: July 15 at 5:00 PM CEST

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

Meeting notes are available at
https://github.com/envmodules/modules/wiki/TSC_meeting_notes_20260715
Next TSC meeting is planned on October 14 5:00 PM CEST

Regards,
Xavier


Le mar. 14 juil. 2026 à 17:34, Xavier Delaruelle <
xav...@gm...> a écrit :

> Dear All,
>
> Our next Technical Steering Committee (TSC) meeting for the Modules
> project will take place on July 15 at 5:00 PM CEST (tomorrow).
>
> This virtual session is open to anyone interested in the project —
> contributors, users, and newcomers are all welcome!
>
> Details and how to connect: https://github.com/envmodules/modules/wiki
>
> Regards,
> Modules maintainers
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#42): https://lists.hpsf.io/g/modules-interest/message/42
Mute This Topic: https://lists.hpsf.io/mt/120267506/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] New feature: Initialize environment variables on first modification

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

It is now possible to define default values for path-like environment
variables (such as MANPATH) before they're first updated, ensuring system
defaults are preserved.

This feature is based on the new "init_envvars" configuration option.

For example, with the following configuration:

$ module config init_envvars MANPATH=

loading a module that prepends a directory to MANPATH:

prepend-path MANPATH /opt/pkg/man

will keep a colon character at the end of MANPATH

$ echo $MANPATH
/opt/pkg/man:


Learn more at
https://modules.readthedocs.io/en/latest/MIGRATING.html#initialize-environment-variables-on-first-modification

Best regards,
Xavier


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#41): https://lists.hpsf.io/g/modules-interest/message/41
Mute This Topic: https://lists.hpsf.io/mt/120277516/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] Next Technical Steering Committee (TSC) meeting: July 15 at 5:00 PM CEST

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

Our next Technical Steering Committee (TSC) meeting for the Modules project
will take place on July 15 at 5:00 PM CEST (tomorrow).

This virtual session is open to anyone interested in the project —
contributors, users, and newcomers are all welcome!

Details and how to connect: https://github.com/envmodules/modules/wiki

Regards,
Modules maintainers


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#40): https://lists.hpsf.io/g/modules-interest/message/40
Mute This Topic: https://lists.hpsf.io/mt/120267506/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] Linked environment variables

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

Next feature release (v5.7) will provide a new configuration option,
"linked_envvars", that lets you link environment variables whose value
change should stay in sync.

See details and example :
https://modules.readthedocs.io/en/latest/MIGRATING.html#linked-environment-variables

Best regards,
Xavier


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#39): https://lists.hpsf.io/g/modules-interest/message/39
Mute This Topic: https://lists.hpsf.io/mt/119936933/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Next Technical Steering Committee (TSC) meeting: May 20 at 5:00 PM CEST

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

Meeting notes are available at
https://github.com/envmodules/modules/wiki/TSC_meeting_notes_20260520
Next TSC meeting is planned on July 15 5:00 PM CEST

Regards,
Xavier


Le mar. 19 mai 2026 à 07:24, Xavier Delaruelle via lists.hpsf.io
<xav...@li...> a écrit :

> Dear All,
>
> Our next Technical Steering Committee (TSC) meeting for the Modules
> project will take place on May 20 at 5:00 PM CEST (tomorrow).
>
> This virtual session is open to anyone interested in the project —
> contributors, users, and newcomers are all welcome!
>
> Details and how to connect: https://github.com/envmodules/modules/wiki
>
> Regards,
> Modules maintainers
>
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#38): https://lists.hpsf.io/g/modules-interest/message/38
Mute This Topic: https://lists.hpsf.io/mt/119386328/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] Next Technical Steering Committee (TSC) meeting: May 20 at 5:00 PM CEST

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Dear All,

Our next Technical Steering Committee (TSC) meeting for the Modules project
will take place on May 20 at 5:00 PM CEST (tomorrow).

This virtual session is open to anyone interested in the project —
contributors, users, and newcomers are all welcome!

Details and how to connect: https://github.com/envmodules/modules/wiki

Regards,
Modules maintainers


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#37): https://lists.hpsf.io/g/modules-interest/message/37
Mute This Topic: https://lists.hpsf.io/mt/119386328/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Shaun D. v. lists.hpsf.i. <Sha...@li...>]

Hi Laurent and Charles,

Thank you for the good advice…

Regarding LD_LIBRARY_PATH, I suspect you are totally correct – I probably don’t need to adjust this. I will try xcelium without setting LD_LIBRARY_PATH. I will also adjust any modules where I’ve unnecessarily added the “arch” bin.

In general though, I still think it was worth while to report the behavior I was seeing with modules and LD_LIBRARY_PATH even if my use case is flawed.

Thank you everyone for the great support

Best regards
Shaun

From: Laurent BESSON <lau...@ea...>
Sent: Monday, May 18, 2026 7:49 AM
To: Orbello Charles (ME-IC/EDS2) <Cha...@fr...>; Shaun Deacon <Sha...@us...>; Xavier Delaruelle <xav...@gm...>
Cc: Environment Modules usage and discussion. <mod...@li...>
Subject: RE: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hello,

I’m fully in line with Charles.

More information can be found on Xcellium required setup for unix here :

https://support.cadence.com/apex/techpubDocViewerPage?xmlName=install.xml&title=Cadence%20Installation%20Guide%20--%20Table%20of%20Contents&hash=&c_version=5.0&path=install/install5.0/installTOC.html

BR,
Laurent.

De : Orbello Charles (ME-IC/EDS2) <Cha...@fr...<mailto:Cha...@fr...>>
Envoyé : lundi 18 mai 2026 14:46
À : Laurent BESSON <lau...@ea...<mailto:lau...@ea...>>; Sha...@us...<mailto:Sha...@us...>; Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Cc : Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Objet : RE: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hello Shaun

under <version>/bin and <version>/tools/bin  you have wrappers that permit to setup the good env .
it’s not a good idea to bypass the wrapping system and use the architecture path

same rule for snps and mg (except some funny tools )

rgds


Charles Orbello
​
From: mod...@li...<mailto:mod...@li...> <mod...@li...<mailto:mod...@li...>> On Behalf Of Laurent BESSON via lists.hpsf.io
Sent: Monday, May 18, 2026 2:32 PM
To: Sha...@us...<mailto:Sha...@us...>; Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hello Shaun,

I checked the Module we use internally to set up Cadence Xcellium for version 25.09 and we do not modify LD_LIBRARY_PATH. Here what « module show » says about this module :

/tool/modules/cadence/xcelium/25.09_e334:

conflict        cadence/xcelium
module          load cadence/licensing/licences
module-whatis   {XCELIUM 25.09_e334 setup}
setenv          VRST_HOME /tool/cadence/xcelium/25.09_e334
setenv          XCELIUM_HOME /tool/cadence/xcelium/25.09_e334
prepend-path    PATH /tool/cadence/xcelium/25.09_e334/bin:/tool/cadence/xcelium/25.09_e334/tools/bin

Have you tried removing LD_LIBRARY_PATH prepend command from your Module setup and see if tool still behaves correctly ?


Best regards,
Laurent.
De : mod...@li...<mailto:mod...@li...> <mod...@li...<mailto:mod...@li...>> De la part de Shaun Deacon via lists.hpsf.io
Envoyé : mercredi 13 mai 2026 21:54
À : Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Cc : Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Objet : Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Xavier,

Thank you for the suggestion…
Unfortunately, this didn’t work – I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to “/sw” in the “socionext” module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io/> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn’t provide a “tcl8.6” sub-directory that would contain ‘init.tcl’
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I’m sure this issue has come up before, but I couldn’t find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#36): https://lists.hpsf.io/g/modules-interest/message/36
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Laurent B. v. lists.hpsf.i. <lau...@li...>]

Hello,

I’m fully in line with Charles.

More information can be found on Xcellium required setup for unix here :

https://support.cadence.com/apex/techpubDocViewerPage?xmlName=install.xml&title=Cadence%20Installation%20Guide%20--%20Table%20of%20Contents&hash=&c_version=5.0&path=install/install5.0/installTOC.html

BR,
Laurent.


De : Orbello Charles (ME-IC/EDS2) <Cha...@fr...>
Envoyé : lundi 18 mai 2026 14:46
À : Laurent BESSON <lau...@ea...>; Sha...@us...; Xavier Delaruelle <xav...@gm...>
Cc : Environment Modules usage and discussion. <mod...@li...>
Objet : RE: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hello Shaun

under <version>/bin and <version>/tools/bin  you have wrappers that permit to setup the good env .
it’s not a good idea to bypass the wrapping system and use the architecture path

same rule for snps and mg (except some funny tools )

rgds


Charles Orbello

​
From: mod...@li...<mailto:mod...@li...> <mod...@li...<mailto:mod...@li...>> On Behalf Of Laurent BESSON via lists.hpsf.io
Sent: Monday, May 18, 2026 2:32 PM
To: Sha...@us...<mailto:Sha...@us...>; Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hello Shaun,

I checked the Module we use internally to set up Cadence Xcellium for version 25.09 and we do not modify LD_LIBRARY_PATH. Here what « module show » says about this module :

/tool/modules/cadence/xcelium/25.09_e334:

conflict        cadence/xcelium
module          load cadence/licensing/licences
module-whatis   {XCELIUM 25.09_e334 setup}
setenv          VRST_HOME /tool/cadence/xcelium/25.09_e334
setenv          XCELIUM_HOME /tool/cadence/xcelium/25.09_e334
prepend-path    PATH /tool/cadence/xcelium/25.09_e334/bin:/tool/cadence/xcelium/25.09_e334/tools/bin

Have you tried removing LD_LIBRARY_PATH prepend command from your Module setup and see if tool still behaves correctly ?


Best regards,
Laurent.
De : mod...@li...<mailto:mod...@li...> <mod...@li...<mailto:mod...@li...>> De la part de Shaun Deacon via lists.hpsf.io
Envoyé : mercredi 13 mai 2026 21:54
À : Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Cc : Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Objet : Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Xavier,

Thank you for the suggestion…
Unfortunately, this didn’t work – I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to “/sw” in the “socionext” module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io/> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn’t provide a “tcl8.6” sub-directory that would contain ‘init.tcl’
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I’m sure this issue has come up before, but I couldn’t find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#35): https://lists.hpsf.io/g/modules-interest/message/35
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Orbello C. (ME-IC/E. v. lists.hpsf.i. <Cha...@li...>]

Hello Shaun

under <version>/bin and <version>/tools/bin  you have wrappers that permit to setup the good env .
it’s not a good idea to bypass the wrapping system and use the architecture path

same rule for snps and mg (except some funny tools )

rgds


Charles Orbello

​
From: mod...@li... <mod...@li...> On Behalf Of Laurent BESSON via lists.hpsf.io
Sent: Monday, May 18, 2026 2:32 PM
To: Sha...@us...; Xavier Delaruelle <xav...@gm...>
Cc: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hello Shaun,

I checked the Module we use internally to set up Cadence Xcellium for version 25.09 and we do not modify LD_LIBRARY_PATH. Here what « module show » says about this module :

/tool/modules/cadence/xcelium/25.09_e334:

conflict        cadence/xcelium
module          load cadence/licensing/licences
module-whatis   {XCELIUM 25.09_e334 setup}
setenv          VRST_HOME /tool/cadence/xcelium/25.09_e334
setenv          XCELIUM_HOME /tool/cadence/xcelium/25.09_e334
prepend-path    PATH /tool/cadence/xcelium/25.09_e334/bin:/tool/cadence/xcelium/25.09_e334/tools/bin

Have you tried removing LD_LIBRARY_PATH prepend command from your Module setup and see if tool still behaves correctly ?


Best regards,
Laurent.
De : mod...@li...<mailto:mod...@li...> <mod...@li...<mailto:mod...@li...>> De la part de Shaun Deacon via lists.hpsf.io
Envoyé : mercredi 13 mai 2026 21:54
À : Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Cc : Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Objet : Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Xavier,

Thank you for the suggestion…
Unfortunately, this didn’t work – I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to “/sw” in the “socionext” module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io/> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn’t provide a “tcl8.6” sub-directory that would contain ‘init.tcl’
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I’m sure this issue has come up before, but I couldn’t find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#34): https://lists.hpsf.io/g/modules-interest/message/34
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Laurent B. v. lists.hpsf.i. <lau...@li...>]

Hello Shaun,

I checked the Module we use internally to set up Cadence Xcellium for version 25.09 and we do not modify LD_LIBRARY_PATH. Here what « module show » says about this module :

/tool/modules/cadence/xcelium/25.09_e334:

conflict        cadence/xcelium
module          load cadence/licensing/licences
module-whatis   {XCELIUM 25.09_e334 setup}
setenv          VRST_HOME /tool/cadence/xcelium/25.09_e334
setenv          XCELIUM_HOME /tool/cadence/xcelium/25.09_e334
prepend-path    PATH /tool/cadence/xcelium/25.09_e334/bin:/tool/cadence/xcelium/25.09_e334/tools/bin

Have you tried removing LD_LIBRARY_PATH prepend command from your Module setup and see if tool still behaves correctly ?


Best regards,
Laurent.
De : mod...@li... <mod...@li...> De la part de Shaun Deacon via lists.hpsf.io
Envoyé : mercredi 13 mai 2026 21:54
À : Xavier Delaruelle <xav...@gm...>
Cc : Environment Modules usage and discussion. <mod...@li...>
Objet : Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Xavier,

Thank you for the suggestion...
Unfortunately, this didn't work - I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to "/sw" in the "socionext" module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn't provide a "tcl8.6" sub-directory that would contain 'init.tcl'
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I'm sure this issue has come up before, but I couldn't find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#33): https://lists.hpsf.io/g/modules-interest/message/33
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Paul M. v. lists.hpsf.i. <pau...@li...>]

You might also want to "protect" the environment variable: TCL_LIBRARY
(after you set it).


On 2026-05-14 1:00 PM, Shaun Deacon via lists.hpsf.io wrote:
> Hi Xavier,
> 
> Thank you so much for your support…
> 
> I decided to go with your second work-around (set TCL_LIBRARY in the modulefile). I prefer not to mess with the vendor tool installation (even if it is broken). I’m also figuring that other modules that may be loaded later in the same session will still be OK with the TCL_LIBRARY environment set.
> 
> Best regards,
> Shaun
> 
> From: Xavier Delaruelle <xav...@gm...>
> Sent: Thursday, May 14, 2026 2:07 AM
> To: Shaun Deacon <Sha...@us...>
> Cc: Environment Modules usage and discussion. <mod...@li...>
> Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH
> 
> Many thanks for these outputs.
> 
> It appears that quarantine mechanism is properly configured and modulecmd.tcl script is using the correct tclsh command (from the OS Tcl installation).
> 
> Issue comes from the Tcl sub-interpreters used to evaluate modulercs and modulefiles. Such interpreters are currently not protected by the quarantine mechanism. I have added an issue to implement such protection also for these sub-interpreters:
> https://github.com/envmodules/modules/issues/623
> 
> In the mean time, to fix the issue you face I suggest you try one of the following:
> 
> * repair the broken Tcl installation (maybe just add an empty init.tcl in one of the listed directory)
> * set TCL_LIBRARY environment variable in the modulefile that enables the broken Tcl installation
>    - and make it point to the proper directory (where a init.tcl can be found)
>    - or add directory relative to Tcl OS installation (/usr/share/tcl8.6)
> 
> Best regards,
> Xavier
> 
> 
> Le mer. 13 mai 2026 à 22:41, Shaun Deacon <Sha...@us...<mailto:Sha...@us...>> a écrit :
> OK, output is as follows…
> 
> %> type module
> module is a function
> module ()
> {
>      unset _mlshdbg;
>      if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then
>          case "$-" in
>              *v*x*)
>                  set +vx;
>                  _mlshdbg='vx'
>              ;;
>              *v*)
>                  set +v;
>                  _mlshdbg='v'
>              ;;
>              *x*)
>                  set +x;
>                  _mlshdbg='x'
>              ;;
>              *)
>                  _mlshdbg=''
>              ;;
>          esac;
>      fi;
>      unset _mlre _mlIFS;
>      if [ -n "${IFS+x}" ]; then
>          _mlIFS=$IFS;
>      fi;
>      IFS=' ';
>      for _mlv in ${MODULES_RUN_QUARANTINE:-};
>      do
>          if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then
>              if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then
>                  _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo ${'$_mlv'}'`' ";
>              fi;
>              _mlrv="MODULES_RUNENV_${_mlv}";
>              _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";
>          fi;
>      done;
>      if [ -n "${_mlre:-}" ]; then
>          eval `eval ${_mlre} /usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;
>      else
>          eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;
>      fi;
>      _mlstatus=$?;
>      if [ -n "${_mlIFS+x}" ]; then
>          IFS=$_mlIFS;
>      else
>          unset IFS;
>      fi;
>      unset _mlre _mlv _mlrv _mlIFS;
>      if [ -n "${_mlshdbg:-}" ]; then
>          set -$_mlshdbg;
>      fi;
>      unset _mlshdbg;
>      return $_mlstatus
> }
> 
> %> type _module_raw
> /bin/type: line 2: type: _module_raw: not found
> 
> %> which tclsh
> /bin/tclsh
> 
> Again, for additional information, our modules installation is here :
> 
> /sw/modules
> 
> Although there is a system version (which we don’t want to use) here :
> 
> /usr/share/Modules
> 
> From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
> Sent: Wednesday, May 13, 2026 1:11 PM
> To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
> Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
> Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH
> 
> Could you provide the output of the following commands:
> 
> type module
> type _module_raw
> which tclsh
> 
> Best regards,
> Xavier
> 
> Le mer. 13 mai 2026 à 21:54, Shaun Deacon <Sha...@us...<mailto:Sha...@us...>> a écrit :
> Hi Xavier,
> 
> Thank you for the suggestion…
> Unfortunately, this didn’t work – I get the same error.
> 
> Just for additional info, the offending tool module does the following :
> 
> %> module display xcelium/test
> -------------------------------------------------------------------
> /sw/modules/modulefiles/cad/cdn/xcelium/test :
> 
> module-whatis   {Xcelium modules environment}
> prereq          socionext
> prepend-path    PATH $CADROOT/cdn/bin
> prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
> prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
> prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
> prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
> prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
> -------------------------------------------------------------------
> 
> Where $CADROOT is set to “/sw” in the “socionext” module.
> 
> Best regards
> Shaun
> 
> From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
> Sent: Wednesday, May 13, 2026 12:38 PM
> To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
> Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
> Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH
> 
> Hi Shaun,
> 
> I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.
> 
> In /etc/environment-modules/initrc, add the following lines:
> 
>    module config quarantine_support 1
>    module config run_quarantine LD_LIBRARY_PATH
> 
> Then restart a new shell session.
> 
> It should protect the module execution from this interfering Tcl installation.
> 
> Best regards,
> Xavier
> 
> 
> Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io> <Sha...@li...<mailto:us....@li...>> a écrit :
> Hi All,
> 
> Module version :
> Modules Release 5.5.0 (2024-11-11)
> Platform :
> Red Hat Enterprise Linux release 8.10 (Ootpa)
> 
> I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn’t provide a “tcl8.6” sub-directory that would contain ‘init.tcl’
> The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries
> 
> Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.
> 
> %> module load  tool-with-lib
> %> module load  another-tool
> 
> ERROR: Can't find a usable init.tcl in the following directories:
>        /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library
> 
>    This probably means that Tcl wasn't installed properly.
> 
>        while executing
>    "error $msg"
>        (procedure "tclInit" line 61)
>        invoked from within
>    "tclInit"
>        invoked from within
>    "interp create $itrp"
>        (procedure "execute-modulerc" line 60)
>        invoked from within
>    "execute-modulerc $dir/$elt $elt $elt"
>        (procedure "getModules" line 101)
>        invoked from within
>    "getModules $dir $mod 0 [list rc_defs_included resolve]"
>        (procedure "getPathToModule" line 49)
>        invoked from within
>    "getPathToModule $mod $modulepath_list $notfounderr"
>        (procedure "cmdModuleLoad" line 30)
>        invoked from within
>    "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
>        (procedure "cmdModuleIntLoad" line 17)
>        invoked from within
>    "$cmdprocname {*}$cmdopts {*}$parsed_args"
>        (procedure "module" line 186)
>        invoked from within
>    "{*}$execcmdlist"
> 
> What is the recommended/best way to get round this issue ?
> I’m sure this issue has come up before, but I couldn’t find answers on the internet.
> 
> Best regards
> Shaun
> 
> --
> Shaun Deacon
> Principal Software Engineer
> Socionext America, Inc.
> --
> 
> CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
> 
> CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
> CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
> CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
> 
> 
> 
> 
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#32): https://lists.hpsf.io/g/modules-interest/message/32
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Shaun D. v. lists.hpsf.i. <Sha...@li...>]

Hi Xavier,

Thank you so much for your support…

I decided to go with your second work-around (set TCL_LIBRARY in the modulefile). I prefer not to mess with the vendor tool installation (even if it is broken). I’m also figuring that other modules that may be loaded later in the same session will still be OK with the TCL_LIBRARY environment set.

Best regards,
Shaun

From: Xavier Delaruelle <xav...@gm...>
Sent: Thursday, May 14, 2026 2:07 AM
To: Shaun Deacon <Sha...@us...>
Cc: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Many thanks for these outputs.

It appears that quarantine mechanism is properly configured and modulecmd.tcl script is using the correct tclsh command (from the OS Tcl installation).

Issue comes from the Tcl sub-interpreters used to evaluate modulercs and modulefiles. Such interpreters are currently not protected by the quarantine mechanism. I have added an issue to implement such protection also for these sub-interpreters:
https://github.com/envmodules/modules/issues/623

In the mean time, to fix the issue you face I suggest you try one of the following:

* repair the broken Tcl installation (maybe just add an empty init.tcl in one of the listed directory)
* set TCL_LIBRARY environment variable in the modulefile that enables the broken Tcl installation
  - and make it point to the proper directory (where a init.tcl can be found)
  - or add directory relative to Tcl OS installation (/usr/share/tcl8.6)

Best regards,
Xavier


Le mer. 13 mai 2026 à 22:41, Shaun Deacon <Sha...@us...<mailto:Sha...@us...>> a écrit :
OK, output is as follows…

%> type module
module is a function
module ()
{
    unset _mlshdbg;
    if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then
        case "$-" in
            *v*x*)
                set +vx;
                _mlshdbg='vx'
            ;;
            *v*)
                set +v;
                _mlshdbg='v'
            ;;
            *x*)
                set +x;
                _mlshdbg='x'
            ;;
            *)
                _mlshdbg=''
            ;;
        esac;
    fi;
    unset _mlre _mlIFS;
    if [ -n "${IFS+x}" ]; then
        _mlIFS=$IFS;
    fi;
    IFS=' ';
    for _mlv in ${MODULES_RUN_QUARANTINE:-};
    do
        if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then
            if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then
                _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo ${'$_mlv'}'`' ";
            fi;
            _mlrv="MODULES_RUNENV_${_mlv}";
            _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";
        fi;
    done;
    if [ -n "${_mlre:-}" ]; then
        eval `eval ${_mlre} /usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;
    else
        eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;
    fi;
    _mlstatus=$?;
    if [ -n "${_mlIFS+x}" ]; then
        IFS=$_mlIFS;
    else
        unset IFS;
    fi;
    unset _mlre _mlv _mlrv _mlIFS;
    if [ -n "${_mlshdbg:-}" ]; then
        set -$_mlshdbg;
    fi;
    unset _mlshdbg;
    return $_mlstatus
}

%> type _module_raw
/bin/type: line 2: type: _module_raw: not found

%> which tclsh
/bin/tclsh

Again, for additional information, our modules installation is here :

/sw/modules

Although there is a system version (which we don’t want to use) here :

/usr/share/Modules

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 1:11 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Could you provide the output of the following commands:

type module
type _module_raw
which tclsh

Best regards,
Xavier

Le mer. 13 mai 2026 à 21:54, Shaun Deacon <Sha...@us...<mailto:Sha...@us...>> a écrit :
Hi Xavier,

Thank you for the suggestion…
Unfortunately, this didn’t work – I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to “/sw” in the “socionext” module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn’t provide a “tcl8.6” sub-directory that would contain ‘init.tcl’
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I’m sure this issue has come up before, but I couldn’t find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#31): https://lists.hpsf.io/g/modules-interest/message/31
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Many thanks for these outputs.

It appears that quarantine mechanism is properly configured and
modulecmd.tcl script is using the correct tclsh command (from the OS Tcl
installation).

Issue comes from the Tcl sub-interpreters used to evaluate modulercs and
modulefiles. Such interpreters are currently not protected by the
quarantine mechanism. I have added an issue to implement such protection
also for these sub-interpreters:
https://github.com/envmodules/modules/issues/623

In the mean time, to fix the issue you face I suggest you try one of the
following:

* repair the broken Tcl installation (maybe just add an empty init.tcl in
one of the listed directory)
* set TCL_LIBRARY environment variable in the modulefile that enables the
broken Tcl installation
  - and make it point to the proper directory (where a init.tcl can be
found)
  - or add directory relative to Tcl OS installation (/usr/share/tcl8.6)

Best regards,
Xavier


Le mer. 13 mai 2026 à 22:41, Shaun Deacon <Sha...@us...> a
écrit :

> OK, output is as follows…
>
>
>
> %> type module
>
> module is a function
>
> module ()
>
> {
>
>     unset _mlshdbg;
>
>     if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then
>
>         case "$-" in
>
>             *v*x*)
>
>                 set +vx;
>
>                 _mlshdbg='vx'
>
>             ;;
>
>             *v*)
>
>                 set +v;
>
>                 _mlshdbg='v'
>
>             ;;
>
>             *x*)
>
>                 set +x;
>
>                 _mlshdbg='x'
>
>             ;;
>
>             *)
>
>                 _mlshdbg=''
>
>             ;;
>
>         esac;
>
>     fi;
>
>     unset _mlre _mlIFS;
>
>     if [ -n "${IFS+x}" ]; then
>
>         _mlIFS=$IFS;
>
>     fi;
>
>     IFS=' ';
>
>     for _mlv in ${MODULES_RUN_QUARANTINE:-};
>
>     do
>
>         if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" =
> "${_mlv#[0-9]}" ]; then
>
>             if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then
>
>                 _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo
> ${'$_mlv'}'`' ";
>
>             fi;
>
>             _mlrv="MODULES_RUNENV_${_mlv}";
>
>             _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";
>
>         fi;
>
>     done;
>
>     if [ -n "${_mlre:-}" ]; then
>
>         eval `eval ${_mlre} /usr/bin/tclsh
> /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;
>
>     else
>
>         eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash
> "$@"`;
>
>     fi;
>
>     _mlstatus=$?;
>
>     if [ -n "${_mlIFS+x}" ]; then
>
>         IFS=$_mlIFS;
>
>     else
>
>         unset IFS;
>
>     fi;
>
>     unset _mlre _mlv _mlrv _mlIFS;
>
>     if [ -n "${_mlshdbg:-}" ]; then
>
>         set -$_mlshdbg;
>
>     fi;
>
>     unset _mlshdbg;
>
>     return $_mlstatus
>
> }
>
>
>
> %> type _*module*_raw
>
> /bin/type: line 2: type: _module_raw: not found
>
>
>
> %> which tclsh
>
> /bin/tclsh
>
>
>
> Again, for additional information, our modules installation is here :
>
>
>
> /sw/modules
>
>
>
> Although there is a system version (which we don’t want to use) here :
>
>
>
> /usr/share/Modules
>
>
>
> *From:* Xavier Delaruelle <xav...@gm...>
> *Sent:* Wednesday, May 13, 2026 1:11 PM
> *To:* Shaun Deacon <Sha...@us...>
> *Cc:* Environment Modules usage and discussion. <
> mod...@li...>
> *Subject:* Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH
>
>
>
> Could you provide the output of the following commands:
>
>
>
> type module
>
> type _module_raw
>
> which tclsh
>
>
>
> Best regards,
>
> Xavier
>
>
>
> Le mer. 13 mai 2026 à 21:54, Shaun Deacon <Sha...@us...>
> a écrit :
>
> Hi Xavier,
>
>
>
> Thank you for the suggestion…
>
> Unfortunately, this didn’t work – I get the same error.
>
>
>
> Just for additional info, the offending tool module does the following :
>
>
>
> %> module display xcelium/test
>
> -------------------------------------------------------------------
>
> /sw/modules/modulefiles/cad/cdn/xcelium/test :
>
>
>
> module-whatis   {Xcelium modules environment}
>
> prereq          socionext
>
> prepend-path    PATH $CADROOT/cdn/bin
>
> prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
>
> prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
>
> prepend-path    LD_LIBRARY_PATH
> $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
>
> prepend-path    LD_LIBRARY_PATH
> $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
>
> prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
>
> -------------------------------------------------------------------
>
>
>
> Where $CADROOT is set to “/sw” in the “socionext” module.
>
>
>
> Best regards
>
> Shaun
>
>
>
> *From:* Xavier Delaruelle <xav...@gm...>
> *Sent:* Wednesday, May 13, 2026 12:38 PM
> *To:* Shaun Deacon <Sha...@us...>
> *Cc:* Environment Modules usage and discussion. <
> mod...@li...>
> *Subject:* Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH
>
>
>
> Hi Shaun,
>
>
>
> I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH
> in the list of env variable to protect from.
>
>
>
> In /etc/environment-modules/initrc, add the following lines:
>
>
>
>   module config quarantine_support 1
>
>   module config run_quarantine LD_LIBRARY_PATH
>
>
>
> Then restart a new shell session.
>
>
>
> It should protect the module execution from this interfering Tcl
> installation.
>
>
>
> Best regards,
>
> Xavier
>
>
>
>
>
> Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io <Shaun.Deacon=
> us....@li...> a écrit :
>
> Hi All,
>
>
>
> Module version :
>
> Modules Release 5.5.0 (2024-11-11)
>
> Platform :
>
> Red Hat Enterprise Linux release 8.10 (Ootpa)
>
>
>
> I have a vendor tool which provides its own shared object libraries
> including a copy of the Tcl libraries but doesn’t provide a “tcl8.6”
> sub-directory that would contain ‘init.tcl’
>
> The module for the vendor tool needs the LD_LIBRARY_PATH environment to be
> adjusted to pick up its custom libraries
>
>
>
> Unfortunately, if the tool library directories are prepended to
> LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.
>
>
>
> %> module load  tool-with-lib
>
> %> module load  another-tool
>
>
>
> ERROR: Can't find a usable init.tcl in the following directories:
>
>       /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6
> /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library
> /tcl8.6.8/library
>
>
>
>   This probably means that Tcl wasn't installed properly.
>
>
>
>       while executing
>
>   "error $msg"
>
>       (procedure "tclInit" line 61)
>
>       invoked from within
>
>   "tclInit"
>
>       invoked from within
>
>   "interp create $itrp"
>
>       (procedure "execute-modulerc" line 60)
>
>       invoked from within
>
>   "execute-modulerc $dir/$elt $elt $elt"
>
>       (procedure "getModules" line 101)
>
>       invoked from within
>
>   "getModules $dir $mod 0 [list rc_defs_included resolve]"
>
>       (procedure "getPathToModule" line 49)
>
>       invoked from within
>
>   "getPathToModule $mod $modulepath_list $notfounderr"
>
>       (procedure "cmdModuleLoad" line 30)
>
>       invoked from within
>
>   "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
>
>       (procedure "cmdModuleIntLoad" line 17)
>
>       invoked from within
>
>   "$cmdprocname {*}$cmdopts {*}$parsed_args"
>
>       (procedure "module" line 186)
>
>       invoked from within
>
>   "{*}$execcmdlist"
>
>
>
> What is the recommended/best way to get round this issue ?
>
> I’m sure this issue has come up before, but I couldn’t find answers on the
> internet.
>
>
>
> Best regards
>
> Shaun
>
>
>
> --
>
> Shaun Deacon
>
> Principal Software Engineer
>
> Socionext America, Inc.
>
> --
>
>
>
> CONFIDENTIALITY NOTE: This electronic message (including any attachments)
> may contain information that is privileged, confidential, and proprietary.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although
> Socionext has taken reasonable precautions to ensure no viruses are present
> in this email, Socionext accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
>
> 
>
> CONFIDENTIALITY NOTE: This electronic message (including any attachments)
> may contain information that is privileged, confidential, and proprietary.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although
> Socionext has taken reasonable precautions to ensure no viruses are present
> in this email, Socionext accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
>
> CONFIDENTIALITY NOTE: This electronic message (including any attachments)
> may contain information that is privileged, confidential, and proprietary.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although
> Socionext has taken reasonable precautions to ensure no viruses are present
> in this email, Socionext accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#30): https://lists.hpsf.io/g/modules-interest/message/30
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Shaun D. v. lists.hpsf.i. <Sha...@li...>]

OK, output is as follows…

%> type module
module is a function
module ()
{
    unset _mlshdbg;
    if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then
        case "$-" in
            *v*x*)
                set +vx;
                _mlshdbg='vx'
            ;;
            *v*)
                set +v;
                _mlshdbg='v'
            ;;
            *x*)
                set +x;
                _mlshdbg='x'
            ;;
            *)
                _mlshdbg=''
            ;;
        esac;
    fi;
    unset _mlre _mlIFS;
    if [ -n "${IFS+x}" ]; then
        _mlIFS=$IFS;
    fi;
    IFS=' ';
    for _mlv in ${MODULES_RUN_QUARANTINE:-};
    do
        if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then
            if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then
                _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo ${'$_mlv'}'`' ";
            fi;
            _mlrv="MODULES_RUNENV_${_mlv}";
            _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";
        fi;
    done;
    if [ -n "${_mlre:-}" ]; then
        eval `eval ${_mlre} /usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;
    else
        eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;
    fi;
    _mlstatus=$?;
    if [ -n "${_mlIFS+x}" ]; then
        IFS=$_mlIFS;
    else
        unset IFS;
    fi;
    unset _mlre _mlv _mlrv _mlIFS;
    if [ -n "${_mlshdbg:-}" ]; then
        set -$_mlshdbg;
    fi;
    unset _mlshdbg;
    return $_mlstatus
}

%> type _module_raw
/bin/type: line 2: type: _module_raw: not found

%> which tclsh
/bin/tclsh

Again, for additional information, our modules installation is here :

/sw/modules

Although there is a system version (which we don’t want to use) here :

/usr/share/Modules

From: Xavier Delaruelle <xav...@gm...>
Sent: Wednesday, May 13, 2026 1:11 PM
To: Shaun Deacon <Sha...@us...>
Cc: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Could you provide the output of the following commands:

type module
type _module_raw
which tclsh

Best regards,
Xavier

Le mer. 13 mai 2026 à 21:54, Shaun Deacon <Sha...@us...<mailto:Sha...@us...>> a écrit :
Hi Xavier,

Thank you for the suggestion…
Unfortunately, this didn’t work – I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to “/sw” in the “socionext” module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...<mailto:xav...@gm...>>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...<mailto:Sha...@us...>>
Cc: Environment Modules usage and discussion. <mod...@li...<mailto:mod...@li...>>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn’t provide a “tcl8.6” sub-directory that would contain ‘init.tcl’
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I’m sure this issue has come up before, but I couldn’t find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.
CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#29): https://lists.hpsf.io/g/modules-interest/message/29
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Shaun D. v. lists.hpsf.i. <Sha...@li...>]

Hi Xavier,

Thank you for the suggestion...
Unfortunately, this didn't work - I get the same error.

Just for additional info, the offending tool module does the following :

%> module display xcelium/test
-------------------------------------------------------------------
/sw/modules/modulefiles/cad/cdn/xcelium/test :

module-whatis   {Xcelium modules environment}
prereq          socionext
prepend-path    PATH $CADROOT/cdn/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
-------------------------------------------------------------------

Where $CADROOT is set to "/sw" in the "socionext" module.

Best regards
Shaun

From: Xavier Delaruelle <xav...@gm...>
Sent: Wednesday, May 13, 2026 12:38 PM
To: Shaun Deacon <Sha...@us...>
Cc: Environment Modules usage and discussion. <mod...@li...>
Subject: Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io<http://lists.hpsf.io> <Sha...@li...<mailto:us....@li...>> a écrit :
Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn't provide a "tcl8.6" sub-directory that would contain 'init.tcl'
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I'm sure this issue has come up before, but I couldn't find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#28): https://lists.hpsf.io/g/modules-interest/message/28
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Could you provide the output of the following commands:

type module
type _module_raw
which tclsh

Best regards,
Xavier

Le mer. 13 mai 2026 à 21:54, Shaun Deacon <Sha...@us...> a
écrit :

> Hi Xavier,
>
>
>
> Thank you for the suggestion…
>
> Unfortunately, this didn’t work – I get the same error.
>
>
>
> Just for additional info, the offending tool module does the following :
>
>
>
> %> module display xcelium/test
>
> -------------------------------------------------------------------
>
> /sw/modules/modulefiles/cad/cdn/xcelium/test :
>
>
>
> module-whatis   {Xcelium modules environment}
>
> prereq          socionext
>
> prepend-path    PATH $CADROOT/cdn/bin
>
> prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/bin
>
> prepend-path    PATH $CADROOT/cdn/org/xcelium/24.03.013/bin
>
> prepend-path    LD_LIBRARY_PATH
> $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/lib/64bit
>
> prepend-path    LD_LIBRARY_PATH
> $CADROOT/cdn/org/xcelium/24.03.013/tools.lnx86/inca/lib/64bit
>
> prepend-path    LD_LIBRARY_PATH $CADROOT/cdn/org/xcelium/24.03.013/lib
>
> -------------------------------------------------------------------
>
>
>
> Where $CADROOT is set to “/sw” in the “socionext” module.
>
>
>
> Best regards
>
> Shaun
>
>
>
> *From:* Xavier Delaruelle <xav...@gm...>
> *Sent:* Wednesday, May 13, 2026 12:38 PM
> *To:* Shaun Deacon <Sha...@us...>
> *Cc:* Environment Modules usage and discussion. <
> mod...@li...>
> *Subject:* Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH
>
>
>
> Hi Shaun,
>
>
>
> I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH
> in the list of env variable to protect from.
>
>
>
> In /etc/environment-modules/initrc, add the following lines:
>
>
>
>   module config quarantine_support 1
>
>   module config run_quarantine LD_LIBRARY_PATH
>
>
>
> Then restart a new shell session.
>
>
>
> It should protect the module execution from this interfering Tcl
> installation.
>
>
>
> Best regards,
>
> Xavier
>
>
>
>
>
> Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io <Shaun.Deacon=
> us....@li...> a écrit :
>
> Hi All,
>
>
>
> Module version :
>
> Modules Release 5.5.0 (2024-11-11)
>
> Platform :
>
> Red Hat Enterprise Linux release 8.10 (Ootpa)
>
>
>
> I have a vendor tool which provides its own shared object libraries
> including a copy of the Tcl libraries but doesn’t provide a “tcl8.6”
> sub-directory that would contain ‘init.tcl’
>
> The module for the vendor tool needs the LD_LIBRARY_PATH environment to be
> adjusted to pick up its custom libraries
>
>
>
> Unfortunately, if the tool library directories are prepended to
> LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.
>
>
>
> %> module load  tool-with-lib
>
> %> module load  another-tool
>
>
>
> ERROR: Can't find a usable init.tcl in the following directories:
>
>       /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6
> /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library
> /tcl8.6.8/library
>
>
>
>   This probably means that Tcl wasn't installed properly.
>
>
>
>       while executing
>
>   "error $msg"
>
>       (procedure "tclInit" line 61)
>
>       invoked from within
>
>   "tclInit"
>
>       invoked from within
>
>   "interp create $itrp"
>
>       (procedure "execute-modulerc" line 60)
>
>       invoked from within
>
>   "execute-modulerc $dir/$elt $elt $elt"
>
>       (procedure "getModules" line 101)
>
>       invoked from within
>
>   "getModules $dir $mod 0 [list rc_defs_included resolve]"
>
>       (procedure "getPathToModule" line 49)
>
>       invoked from within
>
>   "getPathToModule $mod $modulepath_list $notfounderr"
>
>       (procedure "cmdModuleLoad" line 30)
>
>       invoked from within
>
>   "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
>
>       (procedure "cmdModuleIntLoad" line 17)
>
>       invoked from within
>
>   "$cmdprocname {*}$cmdopts {*}$parsed_args"
>
>       (procedure "module" line 186)
>
>       invoked from within
>
>   "{*}$execcmdlist"
>
>
>
> What is the recommended/best way to get round this issue ?
>
> I’m sure this issue has come up before, but I couldn’t find answers on the
> internet.
>
>
>
> Best regards
>
> Shaun
>
>
>
> --
>
> Shaun Deacon
>
> Principal Software Engineer
>
> Socionext America, Inc.
>
> --
>
>
>
> CONFIDENTIALITY NOTE: This electronic message (including any attachments)
> may contain information that is privileged, confidential, and proprietary.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although
> Socionext has taken reasonable precautions to ensure no viruses are present
> in this email, Socionext accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
>
> 
>
> CONFIDENTIALITY NOTE: This electronic message (including any attachments)
> may contain information that is privileged, confidential, and proprietary.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although
> Socionext has taken reasonable precautions to ensure no viruses are present
> in this email, Socionext accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#27): https://lists.hpsf.io/g/modules-interest/message/27
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Shaun D. v. lists.hpsf.i. <Sha...@li...>]

Hi All,

Module version :
Modules Release 5.5.0 (2024-11-11)
Platform :
Red Hat Enterprise Linux release 8.10 (Ootpa)

I have a vendor tool which provides its own shared object libraries including a copy of the Tcl libraries but doesn't provide a "tcl8.6" sub-directory that would contain 'init.tcl'
The module for the vendor tool needs the LD_LIBRARY_PATH environment to be adjusted to pick up its custom libraries

Unfortunately, if the tool library directories are prepended to LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.

%> module load  tool-with-lib
%> module load  another-tool

ERROR: Can't find a usable init.tcl in the following directories:
      /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6 /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library /tcl8.6.8/library

  This probably means that Tcl wasn't installed properly.

      while executing
  "error $msg"
      (procedure "tclInit" line 61)
      invoked from within
  "tclInit"
      invoked from within
  "interp create $itrp"
      (procedure "execute-modulerc" line 60)
      invoked from within
  "execute-modulerc $dir/$elt $elt $elt"
      (procedure "getModules" line 101)
      invoked from within
  "getModules $dir $mod 0 [list rc_defs_included resolve]"
      (procedure "getPathToModule" line 49)
      invoked from within
  "getPathToModule $mod $modulepath_list $notfounderr"
      (procedure "cmdModuleLoad" line 30)
      invoked from within
  "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
      (procedure "cmdModuleIntLoad" line 17)
      invoked from within
  "$cmdprocname {*}$cmdopts {*}$parsed_args"
      (procedure "module" line 186)
      invoked from within
  "{*}$execcmdlist"

What is the recommended/best way to get round this issue ?
I'm sure this issue has come up before, but I couldn't find answers on the internet.

Best regards
Shaun

--
Shaun Deacon
Principal Software Engineer
Socionext America, Inc.
--

CONFIDENTIALITY NOTE: This electronic message (including any attachments) may contain information that is privileged, confidential, and proprietary. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this electronic message in error, please immediately reply to the sender that you have received this communication and destroy the material in its entirety, whether in electronic or hard copy format. Although Socionext has taken reasonable precautions to ensure no viruses are present in this email, Socionext accepts no responsibility for any loss or damage arising from the use of this email or attachments.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#25): https://lists.hpsf.io/g/modules-interest/message/25
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Conflict with Tcl libraries in LD_LIBRARY_PATH

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

Hi Shaun,

I suggest you to enable the quarantine mechanism and set LD_LIBRARY_PATH in
the list of env variable to protect from.

In /etc/environment-modules/initrc, add the following lines:

  module config quarantine_support 1
  module config run_quarantine LD_LIBRARY_PATH

Then restart a new shell session.

It should protect the module execution from this interfering Tcl
installation.

Best regards,
Xavier


Le mer. 13 mai 2026 à 21:23, Shaun Deacon via lists.hpsf.io <Shaun.Deacon=
us....@li...> a écrit :

> Hi All,
>
>
>
> Module version :
>
> Modules Release 5.5.0 (2024-11-11)
>
> Platform :
>
> Red Hat Enterprise Linux release 8.10 (Ootpa)
>
>
>
> I have a vendor tool which provides its own shared object libraries
> including a copy of the Tcl libraries but doesn’t provide a “tcl8.6”
> sub-directory that would contain ‘init.tcl’
>
> The module for the vendor tool needs the LD_LIBRARY_PATH environment to be
> adjusted to pick up its custom libraries
>
>
>
> Unfortunately, if the tool library directories are prepended to
> LD_LIBRARY_PATH, this interferes with the Tcl that modules needs.
>
>
>
> %> module load  tool-with-lib
>
> %> module load  another-tool
>
>
>
> ERROR: Can't find a usable init.tcl in the following directories:
>
>       /vols/mmsimP4_t1b_008/ws/mmsimcm/mmsimcm_dep_0401/nsd_ext_lib/tcltk/tools.lnx86/tcltk-8.6.8/lib/tcl8.6
> /usr/lib/tcl8.6 /lib/tcl8.6 /usr/library /library /tcl8.6.8/library
> /tcl8.6.8/library
>
>
>
>   This probably means that Tcl wasn't installed properly.
>
>
>
>       while executing
>
>   "error $msg"
>
>       (procedure "tclInit" line 61)
>
>       invoked from within
>
>   "tclInit"
>
>       invoked from within
>
>   "interp create $itrp"
>
>       (procedure "execute-modulerc" line 60)
>
>       invoked from within
>
>   "execute-modulerc $dir/$elt $elt $elt"
>
>       (procedure "getModules" line 101)
>
>       invoked from within
>
>   "getModules $dir $mod 0 [list rc_defs_included resolve]"
>
>       (procedure "getPathToModule" line 49)
>
>       invoked from within
>
>   "getPathToModule $mod $modulepath_list $notfounderr"
>
>       (procedure "cmdModuleLoad" line 30)
>
>       invoked from within
>
>   "cmdModuleLoad load 1 $tryload $loadany $tag_list {} {*}$args"
>
>       (procedure "cmdModuleIntLoad" line 17)
>
>       invoked from within
>
>   "$cmdprocname {*}$cmdopts {*}$parsed_args"
>
>       (procedure "module" line 186)
>
>       invoked from within
>
>   "{*}$execcmdlist"
>
>
>
> What is the recommended/best way to get round this issue ?
>
> I’m sure this issue has come up before, but I couldn’t find answers on the
> internet.
>
>
>
> Best regards
>
> Shaun
>
>
>
> --
>
> Shaun Deacon
>
> Principal Software Engineer
>
> Socionext America, Inc.
>
> --
>
>
> CONFIDENTIALITY NOTE: This electronic message (including any attachments)
> may contain information that is privileged, confidential, and proprietary.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is strictly prohibited. If you
> received this electronic message in error, please immediately reply to the
> sender that you have received this communication and destroy the material
> in its entirety, whether in electronic or hard copy format. Although
> Socionext has taken reasonable precautions to ensure no viruses are present
> in this email, Socionext accepts no responsibility for any loss or damage
> arising from the use of this email or attachments.
> 
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#26): https://lists.hpsf.io/g/modules-interest/message/26
Mute This Topic: https://lists.hpsf.io/mt/119302881/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Environment Modules at HPSF conference 2026

[Xavier D. v. lists.hpsf.i. <xav...@li...>]

On Wednesday we had our very first Environment Modules Meeting at #HPSFcon.
Many thanks to all the attendees for the very good discussions we had. A
particular interest has been shown in variants, lua modulefile support and
integration with Spack.

Presentations are available at
https://hpsf2026.sched.com/overview/type/Environment+Modules+Project+Meeting

Regards,
Xavier

Le jeu. 19 févr. 2026 à 00:26, Xavier Delaruelle <
xav...@gm...> a écrit :

> 📣 The Environment Modules Project is hosting a *half-day session* at the *HPSF
> Conference* this March!
>
> Join us to connect, share best practices, and explore the future of
> software environment management in HPC.
>
> 🔗 Schedule & registration:
> https://events.linuxfoundation.org/hpsf-conference/
>
>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#24): https://lists.hpsf.io/g/modules-interest/message/24
Mute This Topic: https://lists.hpsf.io/mt/117888589/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Picking the right module after change in MODULEPATH

[Paul M. v. lists.hpsf.i. <pau...@li...>]

	
Did you try?:

module use "$GIT_ROOT/setup/localmodules"

Also, is your custom_verif specific to each .git repo, or could it be a single module in your standard location (in which case you wouldn't need to change MODULEPATH)?


Or, you could also create a module that does all this for you (and use module switch on that module).

So it could:
Determine the GIT_ROOT
If it has changed:
	in the unload stage:
		unload any modules that are from the old GIT_ROOT
		unuse the old GIT_ROOT
	in the load stage:
		use the new GIT_ROOT
		load the modules for the new GIT_ROOT


You could set up sections for load and unload that will only activate if GIT_ROOT has changed.



On 2026-03-10 3:45 AM, Laurent BESSON wrote:
> Hello Paul,
> 
> 
> 
> Thanks for your valueable feedback! I used to use "module switch" before but I found more elegant to use a simple "module load" (along with "conflict_unload") command. I'll revert to "module switch" then.
> 
> 
> 
> I found also "module reload" would do the trick too: If I add a "module --silent reload" right after changing the MODULEPATH, it works too
> 
> 
> 
> And I had another idea after reading the documentation about MODULEPATH. The doc says:
> 
> 
> 
> Path elements registered in the MODULEPATH environment variable may contain reference to environment variables which are converted to their corresponding value by module command each time it looks at the MODULEPATH value. If an environment variable referred in a path element is not defined, its reference is converted to an empty string.
> 
> 
> 
> So I thought I could place into a variable, say GIT_ROOT, what is returned by `git rev-parse --show-toplevel` and then « module use \$GIT_ROOT/setup/localmodules » but the backslash is not sufficient and I have not found a proper syntax under tcsh to use this trick. Note : GIT_ROOT variable is updated , in my env, when I changed my working directory.
> 
> 
> 
> 
> 
> Last but not least, I'm wondering if a "reload on change" feature would be useful ?
> 
> In this mode, "module load" would analyze the signature of module file (md5sum or something like that) and reload it if signature is different, meaning file has changed, from currently loaded module. The signature could also take into account the path where the module file is found. In that case, it would be another way to solve my issue where the module is found in another directory.
> 
> 
> 
> Of course, such a feature would have an impact on "load" mechanism and should not be "on" by default.
> 
> 
> 
> What do you think ?
> 
> 
> 
> Best regards,
> 
> Laurent.
> 
> 
> 
> -----Message d'origine-----
> De : mod...@li... <mod...@li...> De la part de Paul Markfort via lists.hpsf.io
> Envoyé : lundi 9 mars 2026 17:42
> À : mod...@li...
> Objet : Re: [Modules] Picking the right module after change in MODULEPATH
> 
> 
> 
> Try:
> 
> 
> 
> module switch custom_verif custom_verif
> 
> 
> 
> Make sure you specify custom_verif twice (or it might unload some other module).
> 
> Also module switch will act as a module load if the module to unload is not loaded.
> 
> 
> 
> The issue, is the module command does not load a module that is already loaded (it doesn't know it is a different module).
> 
> 
> 
> 
> 
> A better way to handle this would be (since the two custom_verif modules likely make different changes):
> 
> module unload custom_verif
> 
> cd <new_folder>
> 
> module use --prepend `git rev-parse --show-toplevel`/setup/localmodules
> 
> module load custom_verif
> 
> 
> 
> Note: module unload won't complain if custom_verif is not loaded.
> 
> 
> 
> 
> 
> On 2026-03-09 11:22 AM, Laurent BESSON via lists.hpsf.io wrote:
> 
>> Hello dear Modules community,
> 
>>
> 
>> I have an issue with Modules not loading the « expected » modules files in my unix env. When I say « expected », I mean « the way I thought or would like to behav » 😊.
> 
>> Let me explain the context :
> 
>>
> 
>>
> 
>>     *   Modules version 5.5.0
> 
>>     *   Modules special configuration :  module config conflict_unload 1
> 
>>
> 
>> My unix setup script is under Git and I have Modules files under this Git repo. Here is the beginning of this script :
> 
>>
> 
>> Cd <main branch>
> 
>> module use --prepend `git rev-parse
> 
>> --show-toplevel`/setup/localmodules
> 
>> module load custom_verif
> 
>>
> 
>> The « custom_verif » Modules is under Git and is located in <git
> 
>> root>/setup/localmodules
> 
>>
> 
>> Everything works fine when I start from a fresh terminal/shell or as long as I stay in the same directory.
> 
>>
> 
>> Now, the trouble comes when I change directory. Let’s say I have cloned another branch of the same project in another directory. I setup my shell to work in this new directory :
> 
>>
> 
>> Cd <some branch directory>
> 
>> module use --prepend `git rev-parse
> 
>> --show-toplevel`/setup/localmodules
> 
>> module load custom_verif
> 
>>
> 
>> In that case, « custom_verif » module is not unloaded/reloaded and I
> 
>> keep the content of « custom_verif » as it has been defined in the «
> 
>> main » directory but not in the « some branch » directory. Said
> 
>> another way, I see « custom_verif » in the $LOADEDMODULES variable
> 
>> (this is normal and expected)  and I see the old  « <main
> 
>> branch>/setup/localmodules/custom_verif » in $_LMFILES_. I was
> 
>> expecting to see « <some branch>/setup/localmodules/custom_verif » in
> 
>> this $_LMFILES_
> 
>>
> 
>> I was wondering if there is a trick/setup/configuration in Modules to make it understand the « custom_verif » module MUST BE reloaded in the new context (after the MODULEPATH have changed through « module use ») and must be used from the « branch » directory ?
> 
>>
> 
>> Thanks for your help,
> 
>> Laurent.
> 
>>
> 
>>
> 
>>
> 
>>
> 
>>
> 
>>
> 
>>
> 
> 
> 
> --
> 
> --------------------------------------------------------
> 
> The views and opinions expressed above are strictly those of the author(s).  The content of this message has not been reviewed nor approved by any entity whatsoever.
> 
> --------------------------------------------------------
> 
> Paul FM         Info: http://paulfm.com/~paulfm/
> 
> --------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#23): https://lists.hpsf.io/g/modules-interest/message/23
Mute This Topic: https://lists.hpsf.io/mt/118224577/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Picking the right module after change in MODULEPATH

[Laurent B. v. lists.hpsf.i. <lau...@li...>]

Hello Paul,



Thanks for your valueable feedback! I used to use "module switch" before but I found more elegant to use a simple "module load" (along with "conflict_unload") command. I'll revert to "module switch" then.



I found also "module reload" would do the trick too: If I add a "module --silent reload" right after changing the MODULEPATH, it works too



And I had another idea after reading the documentation about MODULEPATH. The doc says:



Path elements registered in the MODULEPATH environment variable may contain reference to environment variables which are converted to their corresponding value by module command each time it looks at the MODULEPATH value. If an environment variable referred in a path element is not defined, its reference is converted to an empty string.



So I thought I could place into a variable, say GIT_ROOT, what is returned by `git rev-parse --show-toplevel` and then « module use \$GIT_ROOT/setup/localmodules » but the backslash is not sufficient and I have not found a proper syntax under tcsh to use this trick. Note : GIT_ROOT variable is updated , in my env, when I changed my working directory.





Last but not least, I'm wondering if a "reload on change" feature would be useful ?

In this mode, "module load" would analyze the signature of module file (md5sum or something like that) and reload it if signature is different, meaning file has changed, from currently loaded module. The signature could also take into account the path where the module file is found. In that case, it would be another way to solve my issue where the module is found in another directory.



Of course, such a feature would have an impact on "load" mechanism and should not be "on" by default.



What do you think ?



Best regards,

Laurent.



-----Message d'origine-----
De : mod...@li... <mod...@li...> De la part de Paul Markfort via lists.hpsf.io
Envoyé : lundi 9 mars 2026 17:42
À : mod...@li...
Objet : Re: [Modules] Picking the right module after change in MODULEPATH



Try:



module switch custom_verif custom_verif



Make sure you specify custom_verif twice (or it might unload some other module).

Also module switch will act as a module load if the module to unload is not loaded.



The issue, is the module command does not load a module that is already loaded (it doesn't know it is a different module).





A better way to handle this would be (since the two custom_verif modules likely make different changes):

module unload custom_verif

cd <new_folder>

module use --prepend `git rev-parse --show-toplevel`/setup/localmodules

module load custom_verif



Note: module unload won't complain if custom_verif is not loaded.





On 2026-03-09 11:22 AM, Laurent BESSON via lists.hpsf.io wrote:

> Hello dear Modules community,

>

> I have an issue with Modules not loading the « expected » modules files in my unix env. When I say « expected », I mean « the way I thought or would like to behav » 😊.

> Let me explain the context :

>

>

>    *   Modules version 5.5.0

>    *   Modules special configuration :  module config conflict_unload 1

>

> My unix setup script is under Git and I have Modules files under this Git repo. Here is the beginning of this script :

>

> Cd <main branch>

> module use --prepend `git rev-parse

> --show-toplevel`/setup/localmodules

> module load custom_verif

>

> The « custom_verif » Modules is under Git and is located in <git

> root>/setup/localmodules

>

> Everything works fine when I start from a fresh terminal/shell or as long as I stay in the same directory.

>

> Now, the trouble comes when I change directory. Let’s say I have cloned another branch of the same project in another directory. I setup my shell to work in this new directory :

>

> Cd <some branch directory>

> module use --prepend `git rev-parse

> --show-toplevel`/setup/localmodules

> module load custom_verif

>

> In that case, « custom_verif » module is not unloaded/reloaded and I

> keep the content of « custom_verif » as it has been defined in the «

> main » directory but not in the « some branch » directory. Said

> another way, I see « custom_verif » in the $LOADEDMODULES variable

> (this is normal and expected)  and I see the old  « <main

> branch>/setup/localmodules/custom_verif » in $_LMFILES_. I was

> expecting to see « <some branch>/setup/localmodules/custom_verif » in

> this $_LMFILES_

>

> I was wondering if there is a trick/setup/configuration in Modules to make it understand the « custom_verif » module MUST BE reloaded in the new context (after the MODULEPATH have changed through « module use ») and must be used from the « branch » directory ?

>

> Thanks for your help,

> Laurent.

>

>

>

>

>

>

>



--

--------------------------------------------------------

The views and opinions expressed above are strictly those of the author(s).  The content of this message has not been reviewed nor approved by any entity whatsoever.

--------------------------------------------------------

Paul FM         Info: http://paulfm.com/~paulfm/

--------------------------------------------------------












-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#22): https://lists.hpsf.io/g/modules-interest/message/22
Mute This Topic: https://lists.hpsf.io/mt/118224577/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Modules] Picking the right module after change in MODULEPATH

[Paul M. v. lists.hpsf.i. <pau...@li...>]

Try:

module switch custom_verif custom_verif

Make sure you specify custom_verif twice (or it might unload some other module).
Also module switch will act as a module load if the module to unload is not loaded.

The issue, is the module command does not load a module that is already loaded (it doesn't know it is a different module).


A better way to handle this would be (since the two custom_verif modules likely make different changes):
module unload custom_verif
cd <new_folder>
module use --prepend `git rev-parse --show-toplevel`/setup/localmodules
module load custom_verif

Note: module unload won't complain if custom_verif is not loaded.


On 2026-03-09 11:22 AM, Laurent BESSON via lists.hpsf.io wrote:
> Hello dear Modules community,
> 
> I have an issue with Modules not loading the « expected » modules files in my unix env. When I say « expected », I mean « the way I thought or would like to behav » 😊.
> Let me explain the context :
> 
> 
>    *   Modules version 5.5.0
>    *   Modules special configuration :  module config conflict_unload 1
> 
> My unix setup script is under Git and I have Modules files under this Git repo. Here is the beginning of this script :
> 
> Cd <main branch>
> module use --prepend `git rev-parse --show-toplevel`/setup/localmodules
> module load custom_verif
> 
> The « custom_verif » Modules is under Git and is located in <git root>/setup/localmodules
> 
> Everything works fine when I start from a fresh terminal/shell or as long as I stay in the same directory.
> 
> Now, the trouble comes when I change directory. Let’s say I have cloned another branch of the same project in another directory. I setup my shell to work in this new directory :
> 
> Cd <some branch directory>
> module use --prepend `git rev-parse --show-toplevel`/setup/localmodules
> module load custom_verif
> 
> In that case, « custom_verif » module is not unloaded/reloaded and I keep the content of « custom_verif » as it has been defined in the « main » directory but not in the « some branch » directory. Said another way, I see « custom_verif » in the $LOADEDMODULES variable (this is normal and expected)  and I see the old  « <main branch>/setup/localmodules/custom_verif » in $_LMFILES_. I was expecting to see « <some branch>/setup/localmodules/custom_verif » in this $_LMFILES_
> 
> I was wondering if there is a trick/setup/configuration in Modules to make it understand the « custom_verif » module MUST BE reloaded in the new context (after the MODULEPATH have changed through « module use ») and must be used from the « branch » directory ?
> 
> Thanks for your help,
> Laurent.
> 
> 
> 
> 
> 
> 
> 

-- 
--------------------------------------------------------
The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
--------------------------------------------------------
Paul FM         Info: http://paulfm.com/~paulfm/
--------------------------------------------------------


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#21): https://lists.hpsf.io/g/modules-interest/message/21
Mute This Topic: https://lists.hpsf.io/mt/118224577/10150481
Group Owner: mod...@li...
Unsubscribe: https://lists.hpsf.io/g/modules-interest/unsub [mod...@li...]
-=-=-=-=-=-=-=-=-=-=-=-