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
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: environment-modules
Version: el5
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2011-09-01 20:53:15 UTC
Type: ---
Embargoed:


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:

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)

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