Bug 719785 - After Loading a Module the command "module" fails with Cannot Initialize TCL
Summary: After Loading a Module the command "module" fails with Cannot Initialize TCL
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: environment-modules
Version: el5
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-07-08 00:43 UTC by Spenser Gilliland
Modified: 2020-08-26 08:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-09-01 20:53:15 UTC
Type: ---

Attachments (Terms of Use)
Failing modulefile (2.18 KB, application/octet-stream)
2011-07-08 00:43 UTC, Spenser Gilliland
no flags Details
Spec file patch (479 bytes, patch)
2011-08-17 23:44 UTC, Spenser Gilliland
no flags Details | Diff

Description Spenser Gilliland 2011-07-08 00:43:41 UTC
Created attachment 511816 [details]
Failing modulefile

Description of problem:

I have written a modulefile for the 12.4 version of Xilinx DS.  If I load this modulefile using "module load Xilinx" there are no errors reported; however, on subsequent calls to module the following error is returned.

[spenser@scotch environment-modules-3.2.8a]$ module avail
init.c(479):ERROR:161: Cannot initialize TCL
[spenser@scotch environment-modules-3.2.8a]$ 

Version-Release number of selected component (if applicable):

environment-modules-3.2.8a which is the current release in EPEL5 stable.

How reproducible:


Steps to Reproduce:
1. Load Xilinx module
2. Attempt to list available modules 
Actual results:

[spenser@scotch environment-modules-3.2.8a]$ module avail
init.c(479):ERROR:161: Cannot initialize TCL
[spenser@scotch environment-modules-3.2.8a]$ 

Expected results:
[spenser@scotch environment-modules-3.2.8a]$ module avail
------------------------ /usr/share/Modules/modulefiles ------------------------
Xilinx/12.4 module-cvs  modules     use.own
dot         module-info null
[spenser@scotch environment-modules-3.2.8a]$ 

Additional info:

The modulefile is attached.

Comment 1 Spenser Gilliland 2011-08-17 23:44:45 UTC
Created attachment 518775 [details]
Spec file patch

Comment 2 Spenser Gilliland 2011-08-17 23:46:31 UTC
This patch should fix the problem.

It is based on the email here


It's clever but it may be controversial as it does use the setgid bit to prevent LD_LIBRARY_PATH from being altered.  

If there is another way to prevent alteration of LD_LIBRARY_PATH for this binary only feel free to update this bug with a new solution.

Comment 3 Orion Poplawski 2011-08-24 20:54:45 UTC
setgid isn't going to fly.  Perhaps the following:

module ()
    eval `/lib64/ld-linux-x86-64.so.2 --library-path ''
/usr/bin/modulecmd bash $*`

(on a 64bit system; on a 32bit system it would need to use /lib/ld-linux.so.2).

I've sent a message to the modules list and the fedora packaging list to get more thoughts.

Comment 4 Spenser Gilliland 2011-09-01 18:42:00 UTC

module () {
 if [ uname -m == "x86_64" ]; then  
    eval `/lib64/ld-linux-x86-64.so.2 --library-path ` `/usr/bin/modulecmd bash $*`
    eval `/lib/ld-linux.so.2 --library-path ` `/usr/bin/modulecmd bash $*`

Comment 5 Orion Poplawski 2011-09-01 20:53:15 UTC
Yeah, but I really want this to go into upstream.  I'm not going to maintain a Fedora only patch for this issue.

Comment 6 Jens Timmerman 2013-02-15 16:28:46 UTC
I also have this issue, after setting LD_LIBRARY_PATH to a place that contains a libtcl.so that does not play nicely with modulecmd

I just wanted to say that this workaround works for me:
$ LD_LIBRARY_PATH='' modulecmd bash av

Comment 7 tyron woodley 2020-08-26 07:26:41 UTC Comment hidden (spam)

Note You need to log in before you can comment on or make changes to this bug.