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

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...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] Picking the right module after change in MODULEPATH

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

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.




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20): https://lists.hpsf.io/g/modules-interest/message/20
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...]
-=-=-=-=-=-=-=-=-=-=-=-

[Modules] Environment Modules at HPSF conference 2026

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

📣 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 (#19): https://lists.hpsf.io/g/modules-interest/message/19
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] First Technical Steering Committee (TSC) meeting: February 18 at 5:00 PM CET

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

Dear All,

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

Regards,
Xavier

Le mer. 18 févr. 2026 à 15:55, Xavier Delaruelle via lists.hpsf.io
<xav...@li...> a écrit :

> Dear All,
>
> Reminder: our first TSC meeting will start in about 1 hour (5:00 PM CET).
> See https://github.com/envmodules/modules/wiki for connection details
>
> Regards,
> Xavier
>
> Le jeu. 5 févr. 2026 à 11:25, Xavier Delaruelle <
> xav...@gm...> a écrit :
>
>> Dear All,
>>
>> The first Technical Steering Committee (TSC) meeting for the Modules
>> project will take place on February 18 at 5:00 PM CET.
>>
>> This virtual session is open to anyone interested in the project —
>> contributors, users, and newcomers are all welcome!
>>
>> 📌 On the agenda: discussion of the roadmap for the upcoming version 5.7.
>>
>> 🔎 Learn more and join the conversation:
>> https://github.com/envmodules/modules/wiki
>>
>> Regards,
>> Modules maintainers
>>
> 
>
>


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

Re: [Modules] First Technical Steering Committee (TSC) meeting: February 18 at 5:00 PM CET

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

Dear All,

Reminder: our first TSC meeting will start in about 1 hour (5:00 PM CET).
See https://github.com/envmodules/modules/wiki for connection details

Regards,
Xavier

Le jeu. 5 févr. 2026 à 11:25, Xavier Delaruelle <xav...@gm...>
a écrit :

> Dear All,
>
> The first Technical Steering Committee (TSC) meeting for the Modules
> project will take place on February 18 at 5:00 PM CET.
>
> This virtual session is open to anyone interested in the project —
> contributors, users, and newcomers are all welcome!
>
> 📌 On the agenda: discussion of the roadmap for the upcoming version 5.7.
>
> 🔎 Learn more and join the conversation:
> https://github.com/envmodules/modules/wiki
>
> Regards,
> Modules maintainers
>


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

[Modules] [lf-hpsf] 1 Month Until HPSF Conference --> 16-20 March in Chicago 🏙️

[Jennifer B. (L. F. v. lists.hpsf.i. <jbl...@li...>]

We’re only a month away from *HPSF Conference
<https://events.linuxfoundation.org/hpsf-conference/>, 16-20 March** in
Chicago. *⏳ View the schedule
<https://events.linuxfoundation.org/hpsf-conference/program/schedule/>
featuring keynotes and breakout sessions you won’t want to miss. HPSFCon
2026 will also host project meetings including:


   - AMRex
   - Apptainer
   - Chapel
   - Charliecloud
   - Environment Modules
   - Flux Framework
   - HPX
   - Kokkos
   - OpenCHAMI User Summit
   - Spack
   - Trilinos User Group (TUG)

Read our blog on Top 5 Reasons to Attend HPSFCon 2026
<https://hpsf.io/blog/2026/top-5-reasons-to-attend-hpsfcon-2026/>.


Also, we’d love your help in sharing about the event. Feel free to utilize
our Attendee Marketing Kit
<https://docs.google.com/document/d/1vib6zVUyY_u3e2UcMOrtAx_2TbMMT60afKHzAcTiLsY/edit?usp=sharing>
to help get out the word about HPSFCon with your networks.



Don’t forget to *register*
<https://events.linuxfoundation.org/hpsf-conference/register/>* by **February
27* for the Standard Rate before the price increases.



See you in Chicago!



Best,

Jennifer

-- 
Jennifer Bly
Director of Marketing Communications
*HPSF * | *The Linux Foundation*
*https://hpsf.io/ <https://hpsf.io/>*


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

Re: [Modules] Default pagination mode

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

Hi All,

New update: -p and -P abbreviated options have been implemented, as well as
the "paginate" configuration option.

This is merged in main branch.

Best regards;
Xavier

Le mar. 3 févr. 2026 à 18:53, Xavier Delaruelle via lists.hpsf.io
<xav...@li...> a écrit :

> Hi All,
>
> Small update on this pagination topic. Recent git releases provides an
> abbreviated option for --no-pager: -P.
>
> So I have just created an issue to track this feature request:
> https://github.com/envmodules/modules/issues/606
>
> Best regards,
> Xavier
>
> Le sam. 11 oct. 2025 à 17:00, Xavier Delaruelle <
> xav...@gm...> a écrit :
>
>> Hi Marc,
>>
>> Many thanks for your message.
>>
>> I have added a feature request to add a new configure option to define
>> if paginate should be done or not, without changing the pager
>> definition.
>>
>> I have also added another feature request to add an abbreviated
>> version for --paginate option. Maybe -p should be ok, as it seems to
>> be the standard abbreviation used by commands (like git).
>>
>> I do not see any command having a abbreviation for --no-pager. So I
>> would prefer not to have an abbreviation for this one.
>>
>> Best regards,
>> Xavier
>>
>> Le jeu. 9 oct. 2025 à 19:07, Paul Markfort <pau...@gm...> a écrit
>> :
>> >
>> > For now, you could define an alias of, module-no-pager which is just
>> "module --no-pager" (autocomplete would fill it out if you use
>> module-n<TAB>).
>> >
>> > If you set MODULES_PAGER="" (or use --no-pager).
>> > Then you can still pipe the output of things like "module avail"
>> through more, etc (which is what I would expect most users to do if it
>> didn't page by default - in the old days that was not easy as the output of
>> module avail went to stderr).
>> >
>> > If you currently use:  "module avail | cat"  this will also stop paging
>> (any redirection of stdout will turn off paging).
>> >
>> >
>> > I do think it could be helpful to add the ability to change the default
>> to --no-pager, then have a --pager  option to reverse it.
>> > Maybe even a --pager=   (so you can override the default without
>> setting a variable)
>> > That is just --pager  Means use default
>> > or you could use --pager=more
>> >
>> >
>> >
>> > I think pager and paginate do different things (I am not sure what,
>> probably needs more detail in the man page).
>> >
>> >         --no-pager
>> >                Do not pipe message output into a pager.
>> >
>> >         --paginate
>> >                Pipe  all  message  output  into  less  (or  if  set,
>> to  the  command  referred  in
>> >                MODULES_PAGER  variable) if error output stream is a
>> terminal. See also MODULES_PAGER
>> >                section.
>> >
>> >         --redirect
>> >                Send message output to stdout instead of stderr. Only
>> supported on sh, bash, ksh, zsh
>> >                and fish shells.
>> >                 (I think this is the default for information commands
>> like module avail).
>> >
>> >         --no-redirect
>> >                Do not send message output to stdout. Keep it on stderr.
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > On 2025-10-09 4:36 AM, Marc Castells wrote:
>> > > Hi Xavier, All,
>> > >
>> > > Is there a way for a user to configure the default pager mode in
>> Modules? As far as I can see, the options are:
>> > >    a) Disable the pager feature altogether by clearing MODULES_PAGER
>> or assigning it the value "cat". No pagination is available.
>> > >    b) Accept the default pagination with "less -eFKRX" and make the
>> user disable it manually with "-no-pager"
>> > >
>> > > I am looking for a third option:
>> > >    c) Keep "less -eFKRX"  in MODULES_PAGER but allow the default
>> pagination to be no-pager. If the user wanted to paginate the output, they
>> would need to explicitly use "-paginate"
>> > >
>> > > This c) option to me is the most natural behaviour and allows the
>> user to configure a default pagination mode whilst having the option to
>> override it with an explicit command line switch. The current functionality
>> is not neutral as It's skewed towards displaying the output with pagination
>> by default.
>> > >
>> > > While on the subject, would it be possible to consider shortcuts for
>> the "-paginate" and "-no-pager" command line options?
>> > >
>> > > Many thanks,
>> > >
>> > > Marc.
>>
>>


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

[Modules] First Technical Steering Committee (TSC) meeting: February 18 at 5:00 PM CET

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

Dear All,

The first Technical Steering Committee (TSC) meeting for the Modules
project will take place on February 18 at 5:00 PM CET.

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

📌 On the agenda: discussion of the roadmap for the upcoming version 5.7.

🔎 Learn more and join the conversation:
https://github.com/envmodules/modules/wiki

Regards,
Modules maintainers


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