Bug 719785

Summary: After Loading a Module the command "module" fails with Cannot Initialize TCL
Product: [Fedora] Fedora EPEL Reporter: Spenser Gilliland <Spenser309>
Component: environment-modulesAssignee: Orion Poplawski <orion>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: el5CC: bugzilla, jdenemar, orion, tyron6397
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-01 20:53:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Failing modulefile
none
Spec file patch none

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:

Always.

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

http://sourceforge.net/mailarchive/message.php?msg_id=27952351

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 
maybe

module () {
 if [ uname -m == "x86_64" ]; then  
    eval `/lib64/ld-linux-x86-64.so.2 --library-path ` `/usr/bin/modulecmd bash $*`
 else
    eval `/lib/ld-linux.so.2 --library-path ` `/usr/bin/modulecmd bash $*`
 fi
}
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)