modules-interest — Discussion forum for modules usage.

Re: MPKG CVS, Links & Collaboration

[Jimmy E. <jimmy@e.kth.se>]

"Daniel Clark/Cambridge/IBM" <dan...@us...> writes:

> I've been looking for a generalized ports package that would integrate well
> with modules, and MPKG looks like it fills that need. I have a few initial
> questions/comments about MPKG.
> 
> CVS:
> I had this error when trying to do a CVS checkout with
> CVSROOT=/afs/e.kth.se/src/SourceRepository :
> 
> $ cvs co mpkg
> cvs checkout: Updating mpkg
> cvs checkout: failed to create lock directory for
> `/afs/e.kth.se/src/SourceRepository/mpkg'
> (/afs/e.kth.se/src/SourceRepository/mpkg/#cvs.lock): Permission denied
> cvs checkout: failed to obtain dir lock in repository
> `/afs/e.kth.se/src/SourceRepository/mpkg'
> cvs [checkout aborted]: read lock failed - giving up

try "cvs -R co mpkg"  if you have the cvs-nolock-patch.

> It took me a little while to find
> http://www.stacken.kth.se/projekt/arla/#cvs_tree and then go and find the
> source to CVS 1.10 (http://ftp.cvshome.org/cvs-1.10/cvs-1.10.tar.gz), apply
> the cvs-nolock.diff patch, and compile. There may be a race condition
> caused by this patch - (a) reader looks for lock and doesn't see it; (b)
> writer creates lock, and starts writing file; (c) reader opens and reads
> partially written file. I don't know enough C to tell if the patch contains
> countermeaures against this possible problem, but as of the latest CVS
> version (1.11.2) it looks like the behaviour of requiring read-only users
> to be able to write to CVS lock files in the repository or the LockDir
> specified in CVSROOT/config still exists. So if it isn't too much trouble
> it would be useful if anoncvs access could be provided via pserver or the
> ssh method arla seems to use (I tried using anoncvs.stacken.kth.se but mpkg
> doesn't seem to be one of the cvs modules that is rsynced to that server)

mpkg is not a stacken-project, mpkg i developed by the Sysadmin team of the
Departmant of Eletrics at KTH. We compile almost all software with mpkg for
all our plattforms ( Tru64, Linux, Solaris ).

We should really fix a pserver, you a re right, we should also fix some
public mailinglist, the intrest in mpkg is a little bit bigger than we
thought it would be, which of course make us very happy!

> Collaboration:
> In general do you view MPKG as an internal project that others may find
> useful to look at and possibly branch for their own environments

There are 2 trees, one "mpkg" and one "mpkg-configuration", the idea is to
keep our sitespecific stuff in mpkg-configuration.

>, or are
> you interested in accepting / managing contributed ports along the lines of
> the *BSD model?

This would be great, YES!
We would be very happy to see more people writing makefiles.

In the meanwhile just send your patches via mail, in the long run we may
give commit-rights to other serios sites working heavily with mpkg.

/Jimmy

Re: MPKG CVS, Links & Collaboration

[Harlan S. <Har...@pf...>]

If anybody has the time and interest, I would *love* to see modules support
get added (as a policy option) to www.openpackages.org .

I can help make this happen.

H

MPKG CVS, Links & Collaboration

[Daniel Clark/Cambridge/I. <dan...@us...>]

I've been looking for a generalized ports package that would integrate well
with modules, and MPKG looks like it fills that need. I have a few initial
questions/comments about MPKG.

CVS:
I had this error when trying to do a CVS checkout with
CVSROOT=/afs/e.kth.se/src/SourceRepository :

$ cvs co mpkg
cvs checkout: Updating mpkg
cvs checkout: failed to create lock directory for
`/afs/e.kth.se/src/SourceRepository/mpkg'
(/afs/e.kth.se/src/SourceRepository/mpkg/#cvs.lock): Permission denied
cvs checkout: failed to obtain dir lock in repository
`/afs/e.kth.se/src/SourceRepository/mpkg'
cvs [checkout aborted]: read lock failed - giving up

It took me a little while to find
http://www.stacken.kth.se/projekt/arla/#cvs_tree and then go and find the
source to CVS 1.10 (http://ftp.cvshome.org/cvs-1.10/cvs-1.10.tar.gz), apply
the cvs-nolock.diff patch, and compile. There may be a race condition
caused by this patch - (a) reader looks for lock and doesn't see it; (b)
writer creates lock, and starts writing file; (c) reader opens and reads
partially written file. I don't know enough C to tell if the patch contains
countermeaures against this possible problem, but as of the latest CVS
version (1.11.2) it looks like the behaviour of requiring read-only users
to be able to write to CVS lock files in the repository or the LockDir
specified in CVSROOT/config still exists. So if it isn't too much trouble
it would be useful if anoncvs access could be provided via pserver or the
ssh method arla seems to use (I tried using anoncvs.stacken.kth.se but mpkg
doesn't seem to be one of the cvs modules that is rsynced to that server)

Links:
Another item you may want to add to your links page at
http://staff.e.kth.se/mpkg/links.html is GAR, URL
http://gar.lnx-bbc.org/wiki/GarChitecture which looks somewhat similar to
the MPKG idea (except without the modules support). There was recently an
article on GAR in Embedded Linux Journal,
http://www.linuxdevices.com/articles/AT2734738074.html .

Collaboration:
In general do you view MPKG as an internal project that others may find
useful to look at and possibly branch for their own environments, or are
you interested in accepting / managing contributed ports along the lines of
the *BSD model?

Thanks,
--
Daniel Clark § Sys Admin & Assistant Release Engineer
IBM » Lotus » Messaging Technology Group § AIM as djbclark

mpkg user help?

[Harlan S. <Har...@pf...>]

It looks like the mpkg folks are Really Busy.

I'm having mixed success getting mpkg to work under Solaris8 and RedHat7.1.

Might this be a good place to talk about these things?

H

Re: performance

[Mark L. <la...@mi...>]

I agree, that Modules-2.2 seems to run faster than modules 3.+. However, the
problem is that modules-2.2. will not compile with the latest versions of TCL,
and porting it is not worth the effort (I gave it a shot, and then gave up).

But like any free software, anyone is welcome to try to fix it :)

-mark

Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Fri, 10 May 2002, Marvin Wolfthal wrote:

> Hi,
> 
> I've been using Modules for years and just decided to
> see if anyone had done any work on it. So I discovered
> the work at sourceforge and have built 3.1.6 (on Solaris
> 2.7). Unfortunately, even with maximum optimization and
> static linking, it takes several seconds for an xterm to come
> up, about twice as long as the old version.
> Any comments?
> 
> ---------------------------------------------------------
> Marvin Wolfthal ma...@we...
> 
> 

Re: user-setup for v3.1.6 of Modules

[Leo B. <le...@le...>]

On Fri, 2002-05-10 at 14:04, Paul Company wrote:

> Is anyone using user-setup?
> And if so, is there a version of it for Modules-3.1.6?

Hello, Paul.

user-setup hasn't been actively maintained for ages.  It's
possible a user may have done some updates that they can
share.

The modules mailing list is located at the following link
(but isn't responding for me this weekend); perhaps some
other info on user-setup can be found there:

http://www.eng.auburn.edu/users/cross/www/pub/mail-lists/modules-interest/index.html

Regards,

- Leo

performance

[Marvin W. <ma...@we...>]

Hi,

I've been using Modules for years and just decided to
see if anyone had done any work on it. So I discovered
the work at sourceforge and have built 3.1.6 (on Solaris
2.7). Unfortunately, even with maximum optimization and
static linking, it takes several seconds for an xterm to come
up, about twice as long as the old version.
Any comments?

---------------------------------------------------------
Marvin Wolfthal ma...@we...

user-setup for v3.1.6 of Modules

[Paul C. <pj...@no...>]

Is anyone using user-setup?
And if so, is there a version of it for Modules-3.1.6?

Thanks,

--pjc

Re: mpkg (was: automake and libtool under modules )

[Alexander B. <abo@e.kth.se>]

Harlan Stenn <Har...@pf...> writes:

> Has anybody tried recently to install mpkg on a fresh system?
> 
> I've been trying to use the 20020304 tarball and I'm unable to make much
> progress becuase even though the software claims to have an OK boostrap, I
> cannot install many packages because of dependency loops.
> 
> Unfortunately, the mpkg mailing list does not seem to have anybody able to
> help.

Sorry about that. We're all more or less on vacation right now, but I'll
try to fix the bootstrap problems next week.

/abo (mpkg guy)

Re: mpkg (was: automake and libtool under modules )

[Harlan S. <Har...@pf...>]

Has anybody tried recently to install mpkg on a fresh system?

I've been trying to use the 20020304 tarball and I'm unable to make much
progress becuase even though the software claims to have an OK boostrap, I
cannot install many packages because of dependency loops.

Unfortunately, the mpkg mailing list does not seem to have anybody able to
help.

H
--
Ted Stern said:
> Might I recommend to all modules-interested folks the nice software from
> 
>       MPKG
> 
> at
> 
>       http://staff.e.kth.se/mpkg/

Re: Can't find TclX

[Mark L. <la...@mi...>]

Skipping to question #3, there is no "module" binary. There is only the
"modulecmd" binary, and then there is a "module" alias which is defined in the
various $MODULESHOME/init shell files. For instance, the csh alias is
basically:

alias module "eval `modulecmd $*`"

(sloppy syntax, but the gist of the matter).


Regarding TclX, i'm not sure what the advantage of tclx is. I don't use it, but
maybe I'm missing something.

-Mark


> I have three questions:
> 
> Question 1:
> ===========
> Where do you get TclX?
> Their old download site doesn't work.
> ftp://ftp.neosoft.com/pub/tcl/TclX/
> and neither does the Sourceforge download site
> http://sourceforge.net/projects/tclx
> http://sourceforge.net/project/showfiles.php?group_id=13247
> 
> Question 2:
> ===========
> What's the "correct" version of TclX to use?
> 
> When I try to use TclX-8.0.2 I get the following error:
> # make
> gcc -o modulecmd -L/usr/local/lib   -L/usr/openwin/lib -R/usr/openwin/lib
> -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o ModuleCmd_Clear.o
> ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o ModuleCmd_List.o
> ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o ModuleCmd_Update.o
> ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o cmdConflict.o cmdIsLoaded.o
> cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o cmdSetenv.o cmdUname.o
> cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o cmdVersion.o cmdVerbose.o
> cmdWhatis.o init.o locate_module.o utility.o main.o error.o getopt.o
> version.o -ltcl8.3 -ltclx -lXmu -lXt -lX11 -lXext  -ldl -lm -lnsl -lsocket
> Undefined                       first referenced
>  symbol                             in file
> panic                               /usr/local/lib/libtclx.a(tclXdup.o)
> TclWordEnd                          /usr/local/lib/libtclx.a(tclXcmdloop.o)
> TclGetRegError                      /usr/local/lib/libtclx.a(tclXregexp.o)
> TclRegComp                          /usr/local/lib/libtclx.a(tclXregexp.o)
> TclRegExec                          /usr/local/lib/libtclx.a(tclXregexp.o)
> ld: fatal: Symbol referencing errors. No output written to modulecmd
> collect2: ld returned 1 exit status
> make: *** [modulecmd] Error 1
> 
> Question 3:
> ===========
> I can compile without TclX, but then I don't get the
> interface "module" (the main command). I have "modulecmd"
> but not "module". Is this interface command dependent on TclX?
> 
> Thanks,
> 
> Paul
> 
> 
> 
> 

Can't find TclX

[Paul C. <pj...@no...>]

I have three questions:

Question 1:
===========
Where do you get TclX?
Their old download site doesn't work.
ftp://ftp.neosoft.com/pub/tcl/TclX/
and neither does the Sourceforge download site
http://sourceforge.net/projects/tclx
http://sourceforge.net/project/showfiles.php?group_id=13247

Question 2:
===========
What's the "correct" version of TclX to use?

When I try to use TclX-8.0.2 I get the following error:
# make
gcc -o modulecmd -L/usr/local/lib   -L/usr/openwin/lib -R/usr/openwin/lib
-R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o ModuleCmd_Clear.o
ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o ModuleCmd_List.o
ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o ModuleCmd_Update.o
ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o cmdConflict.o cmdIsLoaded.o
cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o cmdSetenv.o cmdUname.o
cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o cmdVersion.o cmdVerbose.o
cmdWhatis.o init.o locate_module.o utility.o main.o error.o getopt.o
version.o -ltcl8.3 -ltclx -lXmu -lXt -lX11 -lXext  -ldl -lm -lnsl -lsocket
Undefined                       first referenced
 symbol                             in file
panic                               /usr/local/lib/libtclx.a(tclXdup.o)
TclWordEnd                          /usr/local/lib/libtclx.a(tclXcmdloop.o)
TclGetRegError                      /usr/local/lib/libtclx.a(tclXregexp.o)
TclRegComp                          /usr/local/lib/libtclx.a(tclXregexp.o)
TclRegExec                          /usr/local/lib/libtclx.a(tclXregexp.o)
ld: fatal: Symbol referencing errors. No output written to modulecmd
collect2: ld returned 1 exit status
make: *** [modulecmd] Error 1

Question 3:
===========
I can compile without TclX, but then I don't get the
interface "module" (the main command). I have "modulecmd"
but not "module". Is this interface command dependent on TclX?

Thanks,

Paul

Re: Building on Solaris 2.6

[Gintautas G. <gi...@ki...>]

You can't and you shouldn't build static binaries on Solaris,
period. See Solaris FAQ, 6.24 "I have problems linking my application
statically".

http://www.science.uva.nl/pub/solaris/solaris2.html

Gintas

> It seems that the "static" build is broken. What was the line you used for
> "./configure" ?
>
>
> -Mark
>
> Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
> MIPS Technologies              Mountain View CA 94043     fax   650-567-5002
>
> On Wed, 8 May 2002, Paul Company wrote:
>
> > I'm running on:
> > Solaris 2.6
> > gcc-3.0.3
> > libstdc++-3.0.95
> > tcl-7.6p2
> > tk-4.2p2
> > tclX-8.0.2
> >
> > I've tried "make"ing but I get the following error:
> >
> > # make
> > gcc -o modulecmd -static -L/usr/local/lib   -L/usr/openwin/lib
> > -R/usr/openwin/lib -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o
> > ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
> > ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o
> > ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o
> > cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o
> > cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o
> > cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o utility.o
> > main.o error.o getopt.o version.o -ltcl7.6  -lXmu -lXt -lX11 -lXext  -lm
> > -lnsl -lsocket
> > Undefined                       first referenced
> >  symbol                             in file
> > dlclose                             /usr/openwin/lib/libX11.a(x11trans.o)
> > dlsym                               /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
> > dlopen                              /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
> > dlerror                             /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
> > ld: fatal: Symbol referencing errors. No output written to modulecmd
> > collect2: ld returned 1 exit status
> > make: *** [modulecmd] Error 1
> >
> > I've tried to compile with tcl-8.3.4 & tk-8.3.4
> > and I get the following error:
> >
> > # make
> > gcc -o modulecmd -static -L/usr/local/lib   -L/usr/openwin/lib
> > -R/usr/openwin/lib -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o
> > ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
> > ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o
> > ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o
> > cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o
> > cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o
> > cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o utility.o
> > main.o error.o getopt.o version.o -ltcl8.3  -lXmu -lXt -lX11 -lXext  -lm
> > -lnsl -lsocket
> > Undefined                       first referenced
> >  symbol                             in file
> > dlclose                             /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> > dlsym                               /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> > dlopen                              /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> > dlerror                             /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> > ld: fatal: Symbol referencing errors. No output written to modulecmd
> > collect2: ld returned 1 exit status
> > make: *** [modulecmd] Error 1
> >
> > Also where do you get TclX.
> > There old download site doesn't work.
> > ftp://ftp.neosoft.com/pub/tcl/TclX/
> >
> > Any suggestions?
> >
> > Thank you,
> >
> > paul

Re: Init file for Makefiles?

[Mark L. <la...@mi...>]

sounds like a good idea. Here's a proposed example usage:



-include Makefile.module

Makefile.module: FORCE
	modulecmd gnumakefile module load foo/1.2 bar/3.4> $@

FORCE:

############# Makefile.module would look like (hopefully) ########
PATH:=/sw/foo/1.2/bin:/sw/bar/3.4/bin:$(PATH)
FOOHOME:=/sw/foo/1.2
LD_LIBRARY_PATH:=/sw/foo/1.2/lib:$(LD_LIBRARY_PATH)

---

An alternate would be

PATH:=$(shell modulecmd pathonly module load foo/1.2 bar/3.4)

but this would only allow setting the path.


I think that make automatically assumes that all included files are
dependencies first, so that Makefile.module would always be made when you run
'make'.

Note that this example does not make use of init files, since the purpose of
the init file is to set the "module" alias, which is not useful in Makefiles.



-Mark


Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Wed, 8 May 2002, Harlan Stenn wrote:

> I notice modules init files for various shells, perl, and python.
> 
> Has somebody written one for, say, GNU make?
> 
> I'm trying to explore the possibility of using the beast for CM stuff, so
> folks can easily use the right tools for a build using "make" and having
> that override things like the user's PATH.
> 
> Yes, I'm trying to find the least offiensive/evil solution to a complex
> situation...
> 
> H
> 

Re: Building on Solaris 2.6

[Mark L. <la...@mi...>]

It seems that the "static" build is broken. What was the line you used for
"./configure" ? 


-Mark

Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Wed, 8 May 2002, Paul Company wrote:

> I'm running on:
> Solaris 2.6
> gcc-3.0.3
> libstdc++-3.0.95
> tcl-7.6p2
> tk-4.2p2
> tclX-8.0.2
> 
> I've tried "make"ing but I get the following error:
> 
> # make
> gcc -o modulecmd -static -L/usr/local/lib   -L/usr/openwin/lib
> -R/usr/openwin/lib -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o
> ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
> ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o
> ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o
> cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o
> cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o
> cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o utility.o
> main.o error.o getopt.o version.o -ltcl7.6  -lXmu -lXt -lX11 -lXext  -lm
> -lnsl -lsocket
> Undefined                       first referenced
>  symbol                             in file
> dlclose                             /usr/openwin/lib/libX11.a(x11trans.o)
> dlsym                               /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
> dlopen                              /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
> dlerror                             /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
> ld: fatal: Symbol referencing errors. No output written to modulecmd
> collect2: ld returned 1 exit status
> make: *** [modulecmd] Error 1
> 
> I've tried to compile with tcl-8.3.4 & tk-8.3.4
> and I get the following error:
> 
> # make
> gcc -o modulecmd -static -L/usr/local/lib   -L/usr/openwin/lib
> -R/usr/openwin/lib -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o
> ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
> ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o
> ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o
> cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o
> cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o
> cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o utility.o
> main.o error.o getopt.o version.o -ltcl8.3  -lXmu -lXt -lX11 -lXext  -lm
> -lnsl -lsocket
> Undefined                       first referenced
>  symbol                             in file
> dlclose                             /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> dlsym                               /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> dlopen                              /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> dlerror                             /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
> ld: fatal: Symbol referencing errors. No output written to modulecmd
> collect2: ld returned 1 exit status
> make: *** [modulecmd] Error 1
> 
> Also where do you get TclX.
> There old download site doesn't work.
> ftp://ftp.neosoft.com/pub/tcl/TclX/
> 
> Any suggestions?
> 
> Thank you,
> 
> paul
> 
> 
> 
> 
> 
> 

Building on Solaris 2.6

[Paul C. <pj...@no...>]

I'm running on:
Solaris 2.6
gcc-3.0.3
libstdc++-3.0.95
tcl-7.6p2
tk-4.2p2
tclX-8.0.2

I've tried "make"ing but I get the following error:

# make
gcc -o modulecmd -static -L/usr/local/lib   -L/usr/openwin/lib
-R/usr/openwin/lib -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o
ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o
ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o
cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o
cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o
cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o utility.o
main.o error.o getopt.o version.o -ltcl7.6  -lXmu -lXt -lX11 -lXext  -lm
-lnsl -lsocket
Undefined                       first referenced
 symbol                             in file
dlclose                             /usr/openwin/lib/libX11.a(x11trans.o)
dlsym                               /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
dlopen                              /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
dlerror                             /usr/local/lib/libtcl7.6.a(tclLoadDl.o)
ld: fatal: Symbol referencing errors. No output written to modulecmd
collect2: ld returned 1 exit status
make: *** [modulecmd] Error 1

I've tried to compile with tcl-8.3.4 & tk-8.3.4
and I get the following error:

# make
gcc -o modulecmd -static -L/usr/local/lib   -L/usr/openwin/lib
-R/usr/openwin/lib -R/usr/openwin/lib:/usr/local/lib -g ModuleCmd_Avail.o
ModuleCmd_Clear.o ModuleCmd_Display.o ModuleCmd_Help.o ModuleCmd_Init.o
ModuleCmd_List.o ModuleCmd_Load.o ModuleCmd_Purge.o ModuleCmd_Switch.o
ModuleCmd_Update.o ModuleCmd_Use.o ModuleCmd_Whatis.o cmdAlias.o
cmdConflict.o cmdIsLoaded.o cmdInfo.o cmdMisc.o cmdModule.o cmdPath.o
cmdSetenv.o cmdUname.o cmdXResource.o cmdUlvl.o cmdLog.o cmdTrace.o
cmdVersion.o cmdVerbose.o cmdWhatis.o init.o locate_module.o utility.o
main.o error.o getopt.o version.o -ltcl8.3  -lXmu -lXt -lX11 -lXext  -lm
-lnsl -lsocket
Undefined                       first referenced
 symbol                             in file
dlclose                             /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
dlsym                               /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
dlopen                              /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
dlerror                             /usr/local/lib/libtcl8.3.a(tclLoadDl.o)
ld: fatal: Symbol referencing errors. No output written to modulecmd
collect2: ld returned 1 exit status
make: *** [modulecmd] Error 1

Also where do you get TclX.
There old download site doesn't work.
ftp://ftp.neosoft.com/pub/tcl/TclX/

Any suggestions?

Thank you,

paul

Init file for Makefiles?

[Harlan S. <Har...@pf...>]

I notice modules init files for various shells, perl, and python.

Has somebody written one for, say, GNU make?

I'm trying to explore the possibility of using the beast for CM stuff, so
folks can easily use the right tools for a build using "make" and having
that override things like the user's PATH.

Yes, I'm trying to find the least offiensive/evil solution to a complex
situation...

H

Hello,meeting notice

[<pos...@bu...>]

Message sent from <web...@bu... >
infected by virus and has not been delivered.
Viruses:
ÉÎÆÉÃÉÒÏ×ÁÎ Win32.HLLM.Klez.4

Original message was stored in the archive.
To receive original message please contact postmaster:
pos...@bu...

Archive record: archive.msg.wV2p9d
	Antivirus service provided by Dr.Web Daemon (www.sald.com)

Re: automake and libtool under modules

[Ted S. <st...@cr...>]

On Fri, 03 May 2002, Harlan Stenn wrote:
> What's a good way to put automake and libtool under modules?
> 
> Libtool wants to override some macro template files and it's difficult to
> tell autoreconf (or embed the info in a Makefile.am) about the location of
> the aclocal stuff.
> 
> Is the better solution to install automake and libtool into the same
> "module"?

Might I recommend to all modules-interested folks the nice software from

      MPKG

at

      http://staff.e.kth.se/mpkg/

We are using it in-house here to set up ports of (at last count) 178 packages,
among which I see automake and libtool.

MPKG is a generic ports package -- it handles the compilation of software on
multiple platforms.  Each package is modularized and the modulefiles are
automatically generated.

Ted
-- 
 Ted Stern                           Engineering Applications
 Cray Inc.                                http://www.cray.com
 411 First Avenue South, Suite 600               206-701-2182
 Seattle, WA 98104-2860                     FAX: 206-701-2500
 gpg fingerprint = 6171 14B3 A323 965B 614D  056F B41C 03AE E404 986C

automake and libtool under modules

[Harlan S. <Har...@pf...>]

What's a good way to put automake and libtool under modules?

Libtool wants to override some macro template files and it's difficult to
tell autoreconf (or embed the info in a Makefile.am) about the location of
the aclocal stuff.

Is the better solution to install automake and libtool into the same
"module"?

H

Re: Modules 3.1.6/RH 7.2/GCC 2.96 compiler warning...

[Mark L. <la...@mi...>]

Mark Lakata, Staff Engineer    1225 Charleston Road       voice 650-567-5170
MIPS Technologies              Mountain View CA 94043     fax   650-567-5002

On Tue, 23 Apr 2002, R.K. Owen Ph.D. wrote:

> On Mon, 22 Apr 2002, Edward Arthur wrote:
> 
> > Hi,
> > 
> > Just thought I'd pass it on...
> > 
> > /home/installs/modules-3.1.6/utility.c:764: the use of `tempnam' is
> > dangerous, better use `mkstemp'
> 
> I have tried to eliminating this message by trying  out the some
> other versions, but they didn't have quite the right properties
> (like using TMPDIR or /tmp, there were other issues), but opted
> to stick with the StdC routine for maximum availability.

I tried it too. The temp file in this case is the file that is created on the
fly for aliases, which is then 'source'd by the parent shell.  That means that
the temp file has to persist after the modulecmd process has finished, and
unfortunately the "recommended" alternatives to tempnam() automatically delete
the file as the program quits.

The only alternative would be to write our own tempnam generator that also
removes the remote possibility of a race condition (that is the reason that
tempnam is "dangerous").  Maybe I'll take a crack at it.

> Perhaps, another more pedestrian approach would be to put the modulecmd
> in /usr/local/bin/, forget the versions modulefile dir,
> with man files in /usr/local/man/, the init files in /usr/local/Modules/init/
> and /usr/local/Modules/modulefiles.  Would still need the rc file
> mods and /etc/custom as described in INSTALL.RH7x.  (Editing the
> /etc/csh.login,csh.cshrc,bashrc,profile files.)

I vote for this approach. As I said, I am working removing the need for the
init/ directory, so that you can just init the modules by doing (assuming
modulecmd is in /usr/local/bin)

eval `modulecmd $shell bootstrap`

The only extern thing that definitely needs to be installed are the module
files of course, but there is no way around that.

(If anyone has a more astheticly pleasing command name to replace "bootstrap"
speak now.)

-Mark


> Most sysadms don't care about modules development and just
> want to install module binaries and trust that they work as advertized.
> 
> What do the other module list think?
> 
> > 
> > Thanks,
> > /Ed
> > 
> 
> 	R.K.
> 
> +------------------+---------------------+
> | R.K.Owen,PhD     | rk...@ow...    |
> | KooZ Software    | Environment Modules |
> | NERSC/LBNL       | rk...@ne...    |
> +------------------+---------------------+
> 
> 

Re: Modules 3.1.6/RH 7.2/GCC 2.96 compiler warning...

[<me...@cs...>]

In reply to R.K. Owen Ph.D. (rk...@ow...):
> Most sysadms don't care about modules development and just
> want to install module binaries and trust that they work as advertized.
> 
> What do the other module list think?

I'd agree however what I do is.
I install them with /soft/rko-modules/(Version)
and then have links in /soft/rko-modules that point to the approprate
bin, init etc...
(its actually a little more complicated because we have multiple
platforms but thats the basic idea)

That way I can have two instances and test out a new version before
switching the default for everyone over.

Kent
-- 
Kent Mein
me...@cs...
http://www.cs.umn.edu/~mein

Re: Modules 3.1.6/RH 7.2/GCC 2.96 compiler warning...

[R.K. O. Ph.D. <rk...@ow...>]

On Mon, 22 Apr 2002, Edward Arthur wrote:

> Hi,
> 
> Just thought I'd pass it on...
> 
> /home/installs/modules-3.1.6/utility.c:764: the use of `tempnam' is
> dangerous, better use `mkstemp'

I have tried to eliminating this message by trying  out the some
other versions, but they didn't have quite the right properties
(like using TMPDIR or /tmp, there were other issues), but opted
to stick with the StdC routine for maximum availability.
> 
> Also, I've never made an RPM but I might volunteer to make one for
> modules (just to learn)
> if there is any interest.  Let me know...

Had been thinking about it, but due to time constraints had never
gotten around to it.  Please go ahead and make one (there's the
beginning of one in the source root as .spec).

My recommendation is to put the module init scripts and binaries
in /usr/local/Modules/3.1.x/ with a link /usr/local/Modules/default
to that dir.
The version specific modulefiles in /usr/local/Modules/versions/
and create /usr/local/Modules/modulefiles/ if not there already.
Also the rpm can install the files in /etc/custom/ as outlined
in the INSTALL.RH7x, etc.

Essential what the RKOconfigure script sets things to and what the
INSTALL.RH7x recommends.
This set-up is designed for modules software development and
allows different versions of modules to be tried out.

However, this is my preference, but others may have other ideas.

(Now I'll flip-flop to my pragmatic mode and argue against this
disasterous idea.)

Perhaps, another more pedestrian approach would be to put the modulecmd
in /usr/local/bin/, forget the versions modulefile dir,
with man files in /usr/local/man/, the init files in /usr/local/Modules/init/
and /usr/local/Modules/modulefiles.  Would still need the rc file
mods and /etc/custom as described in INSTALL.RH7x.  (Editing the
/etc/csh.login,csh.cshrc,bashrc,profile files.)

Most sysadms don't care about modules development and just
want to install module binaries and trust that they work as advertized.

What do the other module list think?

> 
> Thanks,
> /Ed
> 

	R.K.

+------------------+---------------------+
| R.K.Owen,PhD     | rk...@ow...    |
| KooZ Software    | Environment Modules |
| NERSC/LBNL       | rk...@ne...    |
+------------------+---------------------+

Re: Modules 3.1.6/RH 7.2/GCC 2.96 compiler warning...

[Jeff S. <jsq...@la...>]

On Mon, 22 Apr 2002, Edward Arthur wrote:

> /home/installs/modules-3.1.6/utility.c:764: the use of `tempnam' is
> dangerous, better use `mkstemp'

I'd like to second this one -- I see these warnings as well.

> Also, I've never made an RPM but I might volunteer to make one for
> modules (just to learn). if there is any interest.  Let me know...

Note that building an RPM for modules is not a simple thing.  :-(

I recently made a modules RPM for the OSCAR cluster project
(http://oscar.sourceforge.net/).  The next major version of OSCAR will be
using modules as a back-end solution for user environment manipulation.
There's a thin front end called "switcher" that makes persistent changes
to the user's dot files and uses modules on the back end to actually make
all the environment changes.

The "switcher" project is at SourceForge, and although I just populated it
last night (i.e., it's still somewhat rough -- we had been using a private
CVS tree before migrating it to SourceForge), the modules specfile and
script that we use to build it is available in CVS.

See http://env-switcher.sourceforge.net/

-----

The spec file that we made for the modules RPM is definitely OSCAR-ized,
but could probably be genericized fairly easily (just remove some of the
post-processing that we do at the end).  However, when making a modules
RPM, some decisions will definitely have to be made (where to put
modulefiles, etc.).  It's somewhat easier since you can make certain
assumptions since you know this will only be on Linux, but that doesn't
solve all the problems.

I am certainly no RPM expert, but here are some of the difficulties that
we ran into, as well as some of the choices that we made when making the
OSCAR-ized modules RPM:

- modules does not support a "DESTDIR" kind of install.  This makes it
impossible to install modules into somewhere other than $prefix.  This is
a common trick for building RPMs -- you ./configure the package with a
prefix of /usr, but then install it into /var/tmp/rpm-build.$$/$prefix so
that it's easy to bundle up all the files that are installed from that
package into the RPM.

Since modules doesn't support DESTDIR installs, we have to install into
the "real" location where modules is supposed to go.  If you're building
the RPM on a machine where a previous version of the modules RPM is
installed, you have to move the previous version out of the way before you
can install the new one that you are building.  Icky.

I posted to this list about this issue a few weeks ago; converting modules
to use automake is only solution that would solve this problem nicely.  I
haven't looked at the modules configure/build system closely, though -- I
don't know how much effort this would take.

- You have to pick where the modulefiles will be installed.  We chose
/opt/modules/modulefiles -- it seems to be acceptable for the linux FSB,
but others may have religious feelings about where to install them.

- Currently flavors of "man" on linux have the annoying behavior that if
MANPATH is not set, /etc/man.config is used to determine which directories
should be used to find man pages.  If MANPATH is set, then /etc/man.config
is not used.  Hence, MANPATH needs to be loaded with all the directories
from /etc/man.config if any module adds even a single directory to
MANPATH.

We didn't really solve this problem, but it's on our to-do list.  :-(

- We chose not to use all the defaults that are in the skel files from the
modules distribution with respect to setting variables such as
LD_LIBRARY_PATH, etc.  Most linux distros are setup (by default) to not
need any of these variables, and therefore leaving them blank (undefined)
is acceptable (and preferable).

- Recent Linux distros (well, Mandrake and RedHat) have a convenient
mechanism that seemily makes a bunch of things easier: the /etc/profile.d
directory.  If you put scripts in there, they will be run during
shell-setup phases.  So we created /etc/profile.d/00-modules.sh and
/etc/profile.d/00-modules.csh files that do all the setup necessary for
modules.

This didn't turn out to be quite the perfect solution that we thought it
would be -- there were some cases where the 00-modules scripts didn't seem
to get run, and therefore modules didn't get setup properly.  See the next
item.

- Recent Linux distros (well, Mandrake and RedHat) take pains to run as
few shell setup files as possible when running non-interactive remote
shells.  For example:

	rsh somehost who

On the machine "somehost", /etc/bashrc (for bash-flavored shells) and
/etc/csh.cshrc (for csh-flavored shells) is configured to *not* run all
the scripts in /etc/profile.d in this situation (csh splits it into
csh.login [per-login] and csh.cshrc [per-shell].  The profile.d scripts
are only run in csh.login, but rsh/ssh doesn't treat this case as a login
shell, so csh.login does not run).  This created massive difficulty for us
(because one of the main reasons for OSCAR clusters is for cluster
parallelism -- running jobs on multiple nodes simultaneously).

We finally ended up appending /etc/bashrc and /etc/csh.cshrc to manually
source the appropriate 00-modules file if it hadn't already been sourced.
Icky, but effective.

- As a second side effect of this behavior, we had to combine the
once-per-login modules setup and every-shell modules setup into the single
00-modules file.  There's environment variable protection such that the
once-per-login behavior should actually only happen once per login, but
it's still somewhat icky.

- Finally, we had to address the "su problem".  For example, I happen to
prefer the shell tcsh.  If I'm logged in as user "jsquyres" happily using
tcsh and then I su over to root (who uses bash as a default shell), then
the once-per-login modules setup stuff will be all wrong and root won't
have modules setup properly.

So we had to add some more environment variable protection to 00-modules
to ensure that the once-per-login setup stuff runs: a) during login, or b)
when the shell changes.

-----

The contents of http://env-switcher.sourceforge.com/ are still fairly
rough, but they'll be filled out soon -- it's an evolving and continuing
work.

I'd appreciate the comments and feedback from the general modules
community.

{+} Jeff Squyres
{+} jsq...@la...
{+} http://www.lam-mpi.org/

Modules 3.1.6/RH 7.2/GCC 2.96 compiler warning...

[Edward A. <ed...@ul...>]

Hi,

Just thought I'd pass it on...

/home/installs/modules-3.1.6/utility.c:764: the use of `tempnam' is
dangerous, better use `mkstemp'

Also, I've never made an RPM but I might volunteer to make one for
modules (just to learn)
if there is any interest.  Let me know...

Thanks,
/Ed