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.
Related
When compiling, I always place the build in a separate directory. For example:
mkdir build
cd ./build
(cd ..; ./bootstrap)
../configure
make
Since I have plenty of RAM the aim is to compile on a TMPFS.
The script gets the name of the project, uses it for the name for the directory created in $XDG_RUNTIME_DIR/build and finally links it.
# setup-build.sh
#!/usr/bin/bash
set -e
my_project_name=$(basename $(pwd))
my_project_build_dir="$XDG_RUNTIME_DIR/build/$my_project_name"
mkdir -p $my_project_build_dir
ln -s "$my_project_build_dir" "$(pwd)/build"
The script runs without a problem. But, when I do cd ./build; ../configure it returns an error: bash: ../configure: No such file or directory. The file most certainly does exist, but Bash can't find it!
I altered the script to this:
#!/usr/bin/bash
set -e
my_project_src_dir="$(pwd)"
my_project_name="$(basename $(pwd))"
my_project_build_dir="$XDG_RUNTIME_DIR/build/$my_project_name"
mkdir -p "$my_project_build_dir"
ln -s "$my_project_build_dir" "$(pwd)/build"
cd "$my_project_build_dir"
echo "$my_project_src_dir" > "./project-src-dir.txt"
To compile I have to type cd ./build; $(cat ./project-src-dir.txt)/configure; make. This causes Bash complete to partial break, though. As in I can't TAB complete file names from $my_project_src_dir with this method, but TAB completion for arguments works fine. Ifautoconf is needed: (cd $(cat ./project-src-dir.txt); ./bootstrap). If anyone has any other ideas I would still prefer to be able to just do ../configure, although this will have to do for now.
Edit: Had to change my_project_name="$(basename '$my_project_src_dir') to my_project_name="$(basename $(pwd))" as it was taking '$my_project_src_dir' literally.
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
All,
I have a shell script which is attempting to both copy and install a .deb as part of a late_command. I used what I found from this link as a guide.
https://gist.github.com/moonwitch/11100762
Here are the echo commands appending things to the end of lubuntu.seed
echo "d-i preseed/late_command string \ " >> "$WORK_DIR/preseed/lubuntu.seed"
echo "cp /cdrom/pool/extras/my.deb . ; \ " >> "$WORK_DIR/preseed/lubuntu.seed"
echo "d-i preseed/late_command string in-target dpkg -i /cdrom/pool/extras/my.deb ; " >> "$WORK_DIR/preseed/lubuntu.seed"
What really honks me off is the cp command doesn't appear to leave the file on the target no matter what I do. There are some other things I would like to copy and unzip.
I'm working with Ubuntu 15 32-bit. Really don't care about tools that "used to work" with earlier releases. I have spent 3 days searching through every discussion and every example/tool was for a really old version of Ubuntu. Haven't found one which still works today. Some kind of run, but they don't fully function.
My current problem is due to the fact I'm not a packager person, but this has to get done and I didn't get out of the way fast enough.
What I need is an actual functioning cp statement which copies a file from the CD to the target and leaves it there through reboot. So far nothing has.
Thank you
This is the line I used for the late command:
d-i preseed/late_command string cp /cdrom/somefile /target/system/folder && cp /cdrom/someshellscript.sh /target/system/folder && chroot /target chmod a+x /target/system/folder/someshellscript.sh && chroot /target sh /system/folder/someshellscript.sh
I appended the line above to my preseed file. This line basically copies some script from the cdrom or iso to some folder in the target system. During installation the /target folder is the "target" systems root system (get it?).
So for me I copied all the files I need from the CD or iso to some folder like root or opt or even tmp in the target system. Then I changed root to /target and executed all the regular linux commands. Wrote a shell script that executes after all the copying is done to do what I want it to do.
Note:
Inside my shell script, I unset all of the installer's environment stuff:
unset DEBCONF_REDIR
unset DEBCONF_FRONTEND
unset DEBIAN_HAS_FRONTEND
unset DEBIAN_FRONTEND
Then proceed accordingly.
Hope this helps.
Recently I have installed a program called "paradigm". In the program path (/home/hora/Paradigm/) there is a directory "testdata" (/home/hora/Paradigm/testdata) which includes a shell script that runs an example test of the application.The first time I installed the program I was able to run the shell script(runtests.sh) but now that I try to run it I get the error of " No such file or directory", although the files which is mentioned by the error are there. I am sure the problem is due to lack of my knowledge to linux and your help will be appreciated. To show the situation:
hora#serv:~/Paradigm/testdata$ ./runtests.sh
Testing node splitting [1/2], should take seconds
diff: needs_split_1.out: No such file or directory
./runtests.sh: line 6: ../pathwaytab2daifg: No such file or directory
But if I list the content of directory the mentioned files are there:
hora#serv:~/Paradigm/testdata$ ls
complex_family_pathway.tab needs_split_1.cfg needs_split_2.out runtests.sh small_disconnected_pathway.tab
complex_family_pathway.tab.out needs_split_1.out needs_split_2.pathway.tab
And then:
hora#serv:~/Paradigm$ ls
common.h configuration.o
evidencesource.o helperScripts makefile
pathwaytab2daifg.cpp pathwaytab.h test1 configuration.cpp
evidencesource.cpp externVars.cpp main.cpp paradigm
pathwaytab2daifg.o pathwaytab.o testdata configuration.h
evidencesource.h externVars.o main.o pathwaytab2daifg
pathwaytab.cpp README.mediawiki
This is the script content(the problematic part):
#!/bin/bash
set -o pipefail
cd
echo Testing node splitting [1/2], should take seconds
../pathwaytab2daifg needs_split_1.pathway.tab needs_split_1.cfg \
| diff needs_split_1.out - || exit 1
I believe the authors of this script want you to set HOME to ~/Paradigm, or they expect you to install directly in your HOME directory (~) rather than in ~/Paradigm. Either way, this is an error on their part. A simple fix may be to move the installation to ~, or try:
env HOME=$(pwd) ./runtests.sh
(Note that the env is not necessary unless you are running a csh family shell such as csh or tcsh). Setting HOME changes the behavior of cd when called with no arguments and makes the value of HOME the target directory.
This line:
#!/bin/bash
set -o pipefail
cd #<----- here!
echo Testing node splitting [1/2], should take seconds
../pathwaytab2daifg needs_split_1.pathway.tab needs_split_1.cfg \
| diff needs_split_1.out - || exit 1
is changing the directory to ~/, which is the default argument of cd if you don't pass a path to it (see here).
You could fix the script to work from anywhere if you like, by giving cd an absolute path i.e. changing that cd line to cd /home/hora/Paradigm/testdata.
I know this is a VERY old question BUT I think my answer is relevant for others that did not find their answer.
I've been using Linux on a home server since about 2000. Recently, I've upgraded a home server to 64-bit architecture (DELL R510 w/ 2 # Xeon).
I've been using a program (text2pdf.c) since my 32-bit kernel 2.4.32 days. I had forgotten to clean and re-make the executable file before installing it on the 64-bit system. Hence, I received the same error BUT not for the reasons stated in all the answers I've found online. 'which' and 'type' gave no clues BUT using 'file' gave me the info on the libraries that were linked at compile time and they were 2.4.32 libraries. Obviously, OLD 32-bit libraries on a 4.x 64-bit kernel didn't fly. Make clean, make (and make install) cleared the problem.
Peace and blessings,
JQ
I have noticed nmake.exe limits its inference-rule search to one missing file. I find no mention of the problem on the Web. Am I missing something?
$ cat Makefile
.SUFFIXES: .a .b .d .e
all: abc.e
.a.b:
copy $** $#
.b.d:
copy $** $#
.d.e:
copy $** $#
$ touch abc.a
$ nmake
NMAKE : fatal error U1073: don't know how to make 'abc.e'
Stop.
$ nmake -n abc.a
'abc.a' is up-to-date
$ nmake -n abc.b
copy abc.a abc.b
$ nmake -n abc.d
NMAKE : fatal error U1073: don't know how to make 'abc.d'
Stop.
This same Makefile produces tbe following with GNU make:
$ make -n
copy abc* abc.b
copy abc* abc.d
copy abc* abc.e
rm abc.b abc.d
Of course, the $** macro and copy command aren't as useful in with GNU make. ;-)
Does your version of nmake.exe handle this any better? Is there a magic switch? Or is it really as broken as it seems?
The problem here is tracking multi-step operations in your build process. Your source files produce intermediate files of some sort which in turn produce the final build output. In a bad universe, you might make changes to a source file and then your final binaries could still be built from stale versions of the intermediate files. Obviously, that would be bad.
GNU make takes the approach of modeling the entire dependency tree at once, and tracing the modified files all the way through to the output. This is great if make is the only build tool you use. This doesn't work well if you have very large projects, so you need to make them in a specific order. This doesn't work well if 'make' doesn't support some tools of your build process, so you would need to run make multiple times anyway.
nmake.exe takes the approach of doing the simplest possible thing: Only doing one pass at a time. It assumes it will be part of a larger tool chain. So if you have multi-pass dependencies, you will need multiple passes of nmake. If your build process requires more than 3 passes, you are probably doing A Bad Thing and you should fix your process. And for crying out loud, if you need multiple passes, just write a script to do it.