Compiling a Nim program with nim c -r example.nim creates the output file example. I would like to create an output file in another folder with the name bin/example.o which is much easier to gitignore.
What I've tried so far:
nim c -r example.nim -o:bin/example.o
nim c -r example.nim --out:bin/example.o
nim c -r example.nim -o:example.o
nim c -r example.nim --out:example.o
The result of all of these attempts is the same as if I left out the -o/--out option, resulting in an executable example file in the same folder as the example.nim file. The compiler doesn't even accept the option if I don't pass in the -r option (which makes me think I'm misunderstanding the purpose of that option).
I'm using Nim 0.10.3 installed and compiled from the github devel branch source.
What compiler option will allow me to modify the compiled output file?
What you're doing is right, but the options have to be before the file you're compiling. You specify -r to execute the file after compilation, so it will be run with all the arguments specified after the file.
So this should work:
nim c -o:bin/example -r example.nim
nim c -o=bin/example -r example.nim
nim c --out:bin/example -r example.nim
nim c --out=bin/example -r example.nim
Related
I am packaging some Python libraries as RPMs. Some of the libraries are only available as source distributions (no wheels).
In my RPM spec I do:
pip install --root=%{buildroot} --prefix=/x/y tornado
When rpmbuild finishes up it runs check-buildroot, and the build fails with errors like:
Binary file /a/b/c/BUILDROOT/my-rpm-1.0.0-1.el7.x86_64/x/y/lib64/python2.7/site-packages/tornado/speedups.so matches
I see the %{buildroot} path listed if I run strings tornado.so | grep BUILDROOT.
How can I sanitize the .so files? Or more generally, how can I make check-buildroot pass?
I figured out how to remove the paths from the SO files.
I determined that the paths were embedded debug information using this command:
readelf --debug-dump=line speedups.so | less
The strip command can remove debug information from SO files, so I added this to my RPM spec:
BuildRequires: binutils
set +e
find "%{buildroot}{%_prefix}/lib64/python2.7/site-packages" -type f -name "*.so" | while read so_file
do
strip --strip-debug "$so_file"
done
set -e
Note: strip segfaults on some SO files, and it's not clear why. I disabled immediate exits with set +e so that the build ignores them.
I am trying to compile grammar parser https://github.com/RichardMoot/Grail into Linux program according to instructions https://github.com/RichardMoot/Grail/blob/master/README and http://www.labri.fr/perso/moot/tutorial/install.html. There is manual how to create Linux executable from SWI-Prolog code http://www.swi-prolog.org/FAQ/UnixExe.html. All that is fine. But I can not find in the Makefile https://github.com/RichardMoot/Grail/blob/master/Makefile any compilation command. SWI-Prolo uses swipl command for compilation but this Makefile swipl calls only once - for displaying the version of the swipl.
I experience some hardship in installation and compilation, that is fine, I can execute/debug Makefile line by line and arrive at the result. But there is problem in my case - I can not see the ultimate goal in my makefile: which lines are responsible for the production of object files (if necessary) and which lines are responsible for the creation of the final Linux executable.
This is windowed program. The source code and documentation contains warnings about incompatibility with the SWI-Prolog 7, but that is fine, I can resolvem them myself, but as I said - I can not see the Makefile lines for creation of exe.
The source code is created by eminent scientist and I certainly don't want to disturb him by so low-level technical question. I would be happy if he continues work on theory and doesn't waste time on low level programming questions. Hope, that there are SWI-Prolog experts.
I am using latest (7.x) SWI-Prolog on Ubuntu 16.x and I have already installed all the mentioned prerequisites.
If you look closely at the provided Makefile, you'll find that the rules all and install are defined as follows (comments added by me):
all:
-cd source ; $(edit) g3 > g3.tmp # Replaces placeholders for your
# ... GRAIL_ROOT install directory.
-cd source ; mv -f g3.tmp g3 # Overwrites `g3` with the filled file.
cd source ; chmod a+x g3 # Makes it executable.
install: # Essentially copies all files to
-mkdir $(datarootdir) # ... your install directory.
-mkdir $(datadir)
cp -f $(images) $(datadir)
-mkdir $(bindir)
cp -f source/insertdot $(bindir)
chmod a+x $(bindir)/insertdot
cp -f $(resources) $(datadir)
cp -f source/*.pl $(bindir)
cp -f source/g3 $(bindir)
If you then do the common make && make install you'll end up with two folders installed in your Grail directory: bin and share. Inside the binary directory you'll have the g3 file that, regardless of being a SWI-Prolog source, has this initial line:
#!/usr/bin/swipl -q -g start -f
% [... prolog code.]
This header should allow your console terminal to determine what interpreter to use for this script (in this case, swipl). In my case, executing Grail with ./g3 returned a SWI-Prolog message indicating that wrong options/command arguments were used.
According to the man, Unix systems have to use option -s at the end of the header (but this didn't work either in my case):
From the manual:
-s file
Load file as a script. This option may be used from the shell to
make Prolog load a file before entering the toplevel.
It is also used to turn a file into an executable Prolog script
on Unix systems using the following first line
#!/usr/bin/swipl option ... -s
If you want to run this program, simply call the same command from your terminal:
swipl -q -g start -s g3
I need write bash script that uses gcc in a loop to compile all .c source files in current directory into .o object files, and additionally creates .s assembly listings in Intel format. Then, the .o files are linked into run executable.
for i in *
do
gcc -type -f "*.c"
done
i just began that but I'm not sure I began it correctly
Rather them writing a bash script, it's acutally better to write a makefile which is specialised in automatizing this kind of things.
I am using FORTRAN to solve partial differentiate equations. Main program and subroutines have been put in .f file. And I got a .sh file to compile the commands in source code in linux operating system. This file has been attached. But I failed to run this. After struggling for a week, I really need some help on this. Please any help would be greatly appreciated!!!
#!/bin/bash
#
mkdir temp
cd temp
rm *
~/binc/$ARCH/f77split ../fishpack.f
#
for FILE in `ls -1 *.f`;
do
gfortran -c -g $FILE >& compiler.txt
if [ $? -ne 0 ]; then
echo "Errors compiling " $FILE
exit
fi
rm compiler.txt
done
rm *.f
#
ar qc libfishpack.a *.o
rm *.o
#
mv libfishpack.a ~/libf77/$ARCH
cd ..
rmdir temp
#
echo "Library installed as ~/libf77/$ARCH/libfishpack.a."
This looks like the shell script is simply trying to compile a fortran file, but instead of using gfortran's internal toolchain, it is compiling parts manually then linking them together. I have a feeling (though I haven't confirmed) that the call to the program ar is bad, even if it got that far (I'm guessing it should be ar -qc instead of ar qc.).
Anyway, if all the source is in a single fortran file that someone else gave you (fishpack.f), you might be able to compile the whole thing with a single call to gfortran:
gfortran fishpack.f
It should create (by default) an output executable with a filename a.out. If the fortran code is not structured such that it can be lumped into a single file, you may need to work on separating some things out (--as well as updating to at least f90, though that's an aside--).
Good luck.
I have few header files in /my/path/to/file folder. I know how to include these files in new C program but everytime I need to type full path to header file before including it. Can I set some path variable in linux such that it automatically looks for header files ?
You could create a makefile. A minimal example would be:
INC_PATH=/my/path/to/file
CFLAGS=-I$(INC_PATH)
all:
gcc $(CFLAGS) -o prog src1.c src2.c
From here you could improve this makefile in many ways. The most important, probably, would be to state compilation dependencies (so only modified files are recompiled).
As a reference, here you have a link to the GNU make documentation.
If you do not want to use makefiles, you can always set an environment variable to make it easier to type the compilation command:
export MY_INC_PATH=/my/path/to/file
Then you could compile your program like:
gcc -I${MY_INC_PATH} -o prog src1.c src2.c ...
You may want to define MY_INC_PATH variable in the file .bashrc, or probably better, create a file in a handy place containing the variable definition. Then, you could use source to set that variable in the current shell:
source env.sh
I think, however, that using a makefile is a much preferable approach.
there is a similar question and likely better solved (if you are interested in a permanent solution): https://stackoverflow.com/a/558819/1408096
Try setting C_INCLUDE_PATH (for C header files) or CPLUS_INCLUDE_PATH (for C++ header files).
Kudos:jcrossley3
I'm not in Linux right now and I can't be bothered to reboot to check if everything's right, but have you tried making symbolic links? For example, if you are on Ubuntu:
$ cd /usr/include
$ sudo ln -s /my/path/to/file mystuff
So then when you want to include stuf, you can use:
#include <mystuff/SpamFlavours.h>