Do you know a way to automatically generate the modulefile for Intel compilers without using the env2 script?
Using latest version of Modules (v4.6+), the module command gets a new sub-command called sh-to-mod that translates the environment changes performed by a given script into modulefile commands.
$ module sh-to-mod sh /path/to/foo-1.2/foo-setup.sh arg1
#%Module
prepend-path PATH /path/to/foo-1.2/bin
set-alias foo {foobin -q -l}
setenv FOOENV arg1
The source-sh modulefile Tcl command is also introduced in version 4.6 of Modules to directly translate the environment changes performed by a given script as if it was the content of the modulefile currently being evaluated.
On older version of Modules, a standalone script named createmodule.py is provided to achieve such script to modulefile translation.
Related
I'm writing a GitHub Actions workflow that will run on Linux, Windows, and macOS. To avoid redundancy, I want to use the same steps on all platforms as far as possible. This includes UNIX commands like curl and tar that aren't available in PowerShell, the default shell on Windows. So I'm planning to explicitly set the shell to bash on all platforms.
Which brings up the problem: bash expects UNIX paths in commands, but from the documentation, it seems that all environment variables contain platform-specific paths. So on Windows, all environment variables will contain Windows paths. How can I convert them to UNIX paths for use in bash?
Edit: Clarifications:
The paths I'm talking about are environment variables set by GitHub Actions such as GITHUB_WORKSPACE.
For each step of a job, GitHub Actions allows me to explicitly specify the shell to be used. So running bash on Windows in a one-liner in GitHub Actions and doesn't require any installation.
This question is primarily about best practices in GibHub Actions, not about what is possible using bash scripts. If the only way to convert the path is to use a bash script, then #Yahampath's comment answers my question. But I was hoping the GitHub team had thought of a more elegant solution.
I need to build Activestate TCL for Ubuntu 18.04 with memory option enabled, "--enable-symbols=mem flag to the configure script" but there is no configure script in my download, only these, which don't have a "configure" line in them.
license-at8.6-thread.
update_check
komodo_download
payload
README-8.6-thread.txt
pdemos
install_welcome.txt
install.tcl
install.sh
install_lib.tcl
install_images
MANIFEST_at8.6.txt
install_data.tcl
Can someone describe how to add the switch described above for Ubuntu?
.
In order to set the mem option, you'll need to compile Tcl from source. To do that you'll need to get a C build chain (especially a C compiler such as gcc or clang, and make to act as a build orchestrator) and the Tcl (and Tk) source code for the version you want to build. The official location for releases of Tcl sources is on SourceForge:
https://sourceforge.net/projects/tcl/files/Tcl/
Pick the version you need and the download package you prefer (ZIP or compressed Tar archive).
Once you've downloaded and unpacked the Tcl code, change into the appropriate directory within the distribution (e.g., unix for Linux builds) and run the configure script inside; it's that script that you pass the --enable-symbols=mem option to.
ActiveTcl is essentially built the same way (except without symbols at all; it's a production distribution after all). It's main distinguishing feature is that it is set up with access to lots of extra packages to go with it. The same goes for most Linux distributions' own tcl packages. They're all production distributions and aren't configured for memory debugging precisely because that adds a lot of overhead to the code (both time and space).
I'm trying to install modules from SourceForge and I'm getting an error that a variable named TCL_LIB_SPEC is not set. What is this supposed to be set to?
The answer here is to install the TCL development package
% yum install tcl-devel
This gives you a tclConfig.sh file at /usr/lib64/tcl8.5
So
% cd /usr/lib64/tcl8.5
% . ./tclConfig.sh
Then configure works.
It's supposed to be set to the instructions to use with your compiler for linking against the Tcl C library, and it should (conventionally) be generated by running the relevant configure script inside a Tcl source distribution. Or a distribution of Tcl (e.g., on Linux perhaps called tcl-dev) may have alternate correct values already set up.
I went forward and compiled an existing c code via llvm-gcc -emit-llvm -c to llvm bitcode. The c program consisted of four modules which I built to one big bitcode each via llvm-ld. Then I tried to merge these 4 bitcode files to one via llvm-ld GE.bc GA.bc SD.bc SH.bc -o prog which works without complaint.
Trying to execute the bitcode though it complains:
LLVM ERROR: Program used external function 'myFunction' which could not be resolved!
The thing is myFunction should be defined in SD.bc and used also in GA.bc.
But it's not to find in SD.bc - does llvm-ld skip all definitions that are not used!?
My OS is Linux and I use llvm version 2.6.
As a note llvm is on version 2.9 with 3.0 approaching. You should really upgrade.
How can I set up MySQL so that i can have header-files and libraries in my Cygwin gcc C++ builds?
I have seen descriptions on the web, but it seems to refer to stuff I don't have, Like "configure.
(I suspect MySQL has changed their build system).
Using an older version could be an option, but I would prefer to have the same versions as on Linux.
I have a full Cygwin install.
First, what's wrong with just using the Windows version? It works fine.
Then, I've wanted to do the same thing as you, and it can be done. Note that I haven't attempted to build the server; all I was interested in was the MySQL client library so I could do some simple client development in the Cygwin environment.
So what do you have to do in order to build the client library on Cygwin?
First, get the tarball. I used mysql-5.5.13.tar.gz. Unpack it in a suitable location, like /usr/local/src.
Then, install the CMake build system via the Cygwin installer. MySQL has switched from GNU Autotools to CMake. CMake is a meta-build system. It generates Makefiles and other build scripts for specific build environments.
Of course, you also need make and gcc.
I had to apply an innocuous little patch posted on the MySQL forum by one Hiroaki Kawai in order to get the stuff to compile:
Finally, I renamed all dtoa() to _dtoa() in mysql/strings/dtoa.c.
The function is static, and should be safe to be renamed.
You can patch using Perl:
perl -pi.orig -e 's/\bdtoa\b/_dtoa/g' strings/dtoa.c
Then, in the top source directory, type:
cmake .
make mysqlclient
You'll get two static libraries in libmysql/, libclientlib.a and libmysqlclient.a. I don't know that the former is (possibly just a build artefact), but the latter is the real thing.
cp /usr/local/src/mysql-5.5/libmysql/libmysqlclient.a /usr/local/lib/
But it's static, and you likely want a dynamic library. This is where the Cygwin docs come in handy. So:
module=mysqlclient
gcc -shared -o cyg${module}.dll \
-Wl,--out-implib=lib${module}.dll.a \
-Wl,--export-all-symbols \
-Wl,--enable-auto-import \
-Wl,--whole-archive lib${module}.a \
-Wl,--no-whole-archive -lz
That'll create the shared library cygmysqlclient.dll and the import library libmysqlclient.dll.a. Copy both to /usr/local/bin. And that's it.
Here's another question on building the MySQL client library on Cygwin.