Can someone please help me interpret this? I am trying to install PLAN (a Packet Language for Active Networks). From my terminal on Mac OS X 10.8.4:
hntvlan569:~ Scott_Andrew_Collins$ cd OCamlPLAN
hntvlan569:OCamlPLAN Scott_Andrew_Collins$ cd plan-3.22/
hntvlan569:plan-3.22 Scott_Andrew_Collins$ make
ocamlc.opt -pp "camlp4o pa_ifdef.cmo -DPLAN_UNSAFE -DPLANPORT_TCP -DC_CRYPTO" -w s
-thread -I basis -I interpreter -I planet -I port -I util -I RIP -I resident -I
arp -I csum -I frag -I net -I reliable -I dns -I exp -I flow -I security -I
crypto -I builder -I snap -I apps -I common -c common/critical.ml -o
common/critical.cmo Camlp4: Uncaught exception: DynLoader.Error ("pa_ifdef.cmo",
"file not found in path")
Error while running external preprocessor
Command line: camlp4o pa_ifdef.cmo -DPLAN_UNSAFE -DPLANPORT_TCP -DC_CRYPTO
'common/critical.ml' >
/var/folders/pm/m53jrwbd10x0q701d7sw2zrw0000gp/T/ocamlpp9101d0
make: *** [common/critical.cmo] Error 2
You don't say the version of OCaml you're using.
The missing file pa_ifdef.cmo is (perhaps obviously) a preprocessing plugin for camlp4. Looking through the OCaml releases on my system, I see that it was present (maybe in an unsupported form) under OCaml 3.12 but is not there for OCaml 4 (unless I missed it somehow). I suspect support for this plugin has been dropped.
I've used this plugin myself; its purpose is roughly the same as cpp, the C preprocessor. I.e., it does conditional compilation based on tests of flags supplied at compile time.
In recent years I've been lucky enough to do without conditional compilation, so I don't know the latest status of this facility. But it wouldn't surprise me at all if there were a similar plugin that works with the most recent OCaml compiler. So, one solution would be to look into the recent camlp4 and find the replacement.
If the compile-time conditions aren't used widely in your sources you could also go through and remove them.
Another choice would be to compile with an older version of OCaml.
Related
I have installed the mysql connector for c++. I am writing a c++ cgi app. The cgi page has been compiling. I rebooted yesterday and it stopped compiling. g++ -o sales.cgi sales.cpp -lcgicc -lmysqlcppcon. Gives the following error. /usr/bin/ld cannot find -lmysqlcppcon
apt-get tells me I have the latest version of libmysqlcppconn7v5 and i have the latest version of libmyqlcppconn-dev. How do I find the library. I checked /usr/lib/ but I have no idea what I should be looking for.
Since you installed with apt-get, then you can use dpkg to determine which files were installed.
EXAMPLE (you would substitute "mysqlcppcon"):
dpkg -l|grep -i mysql
ii php-mysql 1:7.2+60ubuntu1 all MySQL module for PHP [default]
... <= Search for the exact package name (here, "php-mysql")
dpkg -L php-mysql
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/php-mysql
/usr/share/doc/php-mysql/copyright
/usr/share/doc/php-mysql/changelog.gz
<= List files installed to your system from that package
You can also use find
EXAMPLE:
find / -name "*mysqlcppcon*" -print 2> /dev/null
The *xxx* syntax let's you do a wildcard search; 2> /dev/null filters out irrelevant"noise" from your wildcard search, like "find: ‘/run/lvm’: Permission denied".
Thanks for all of the help. Huge typo on my side. I needed g++ -o sales.cgi sales.cpp -lcgicc -lmysqlcppconn
I am currently trying to install NIST's sclite, which is part of SCTK 2.4.0 (github or current version). I am attempting the install on Cygwin in bash. The installation is done using make.
What I've Done
I made a directory for the install and navigated to that directory
mkdir sctk2.4.0
cd sctk2.4.0
( You'll possibly need $ cd /path/to/dir/sctk2.4.0 .)
I cloned the project from github
git clone https://github.com/chinshr/sctk.git
navigated into the base folder
cd sctk
then I started following the instructions in the INSTALL file.
Running
make config
worked fine, but after typing
make all
I got the output that follows
(mkdir -p bin)
(cd src; make all)
make[1]: Entering directory '/cygdrive/c/David/programs/sctk2.4.0/sctk/src'
(cd asclite; make all)
make[2]: Entering directory '/cygdrive/c/David/programs/sctk2.4.0/sctk/src/asclite'
(cd core; make all)
make[3]: Entering directory '/cygdrive/c/David/programs/sctk2.4.0/sctk/src/asclite/core'
g++ -o asclite -g -Os alignment.o segment.o sgml_reportgenerator.o alignedsegmentiterator.o reportgenerator.o speechset.o segmentsgroup.o logger.o tokenalignment.o sgml_generic_reportgenerator.o recording.o statistics.o compressedlevenshteinmatrix.o segmentor.o id.o trntrn_segmentor.o linestyle_inputparser.o inputparser.o levenshteinmatrix.o levenshtein.o uemfilter.o speakermatch.o spkrautooverlap.o graphalignedsegment.o rawsys_reportgenerator.o graphalignedtoken.o timedobject.o stt_scorer.o aligner.o arraylevenshteinmatrix.o graph.o main.o trn_inputparser.o alignedspeech.o token.o alignedsegment.o graph_coordinate.o rttm_inputparser.o scorer.o properties.o ctmstmrttm_segmentor.o filter.o speech.o alignedspeechiterator.o stm_inputparser.o checker.o ctm_inputparser.o lzma/LzFind.o lzma/LzmaEnc.o lzma/Alloc.o lzma/LzmaLib.o lzma/LzmaDec.o -lm
alignment.o: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
make[3]: *** [makefile:62: asclite] Error 1
make[3]: Leaving directory '/cygdrive/c/David/programs/sctk2.4.0/sctk/src/asclite/core'
make[2]: *** [makefile:12: all] Error 2
make[2]: Leaving directory '/cygdrive/c/David/programs/sctk2.4.0/sctk/src/asclite'
make[2]: *** [makefile:12: all] Error 2
make[2]: Leaving directory '/cygdrive/c/David/programs/sctk2.4.0/sctk/src'
make: *** [makefile:20: all] Error 2
I've looked at this SO post, but I've determined that the alignment.o file is not corrupted. Just in case, I tried a few make clean and even re-cloned the project from github, but I still get the same error.
Can anyone help me complete this installation, or at least get to the next step?
System Details
$ uname -a
CYGWIN_NT-6.1 MyMachine 2.10.0(0.325/5/3) 2018-02-02 15:16 x86_64 Cygwin
$ bash --version
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin) ...
$ gcc --version
gcc (GCC) 6.4.0 ...
$ g++ --version
g++ (GCC) 6.4.0 ...
$ make --version
GNU Make 4.2.1
Built for x86_64-unknown-cygwin ...
$ systeminfo | sed -n 's/^OS\ *//p'
Name: Microsoft Windows 7 Enterprise
Version: 6.1.7601 Service Pack 1 Build 7601
Manufacturer: Microsoft Corporation
Configuration: Member Workstation
Build Type: Multiprocessor Free
Note
I'm asking about this problem and then giving an answer to my own question. (I like that StackOverflow is allowing us to do that.) Hopefully, this will make it easier for people to help me with the problems I ran into further in the installation.
The next problem I ran into is discussed here. You can see this next problem in the answer to this problem.
This is the 'EASIER' solution.
Here are the details on what I called "the kaldi solution". Right now, it's just a list of commands without details. As shown here, these commands will install a sclite-2.4.10 directory under the $HOME (~) directory:
$ cd
$ git clone https://github.com/kaldi-asr/kaldi.git
$ cd kaldi/tools
$ extras/check_dependencies.sh
$ make -j $(nproc --all)
$ cp -R sctk-2.4.10 ~/
$ cd
$ rm -rf kaldi
$ cd sctk-2.4.10/
$ cp $HOME/.bashrc "${HOME}/.bashrc.$(date +%Y%m%d-%H%M%S).bak"
$ echo -e "\n\n## Allow access to sclite, rfilter, etc" >> $HOME/.bashrc
$ echo 'export PATH='"$(pwd)/bin"':$PATH' >> $HOME/.bashrc
$ source ~/.bashrc
See this question/answer for details on how to use it on Windows.
(See my comment under the question for the kaldi solution.)
The solution to this problem was in the README, as solutions often are. Note: There was another problem which came up after this problem was solved. See the bottom of this answer for help with that.
Here is the command I used to get the pertinent info from the README.
cat README | tail -13
and here is the pertinent info
64 bits Compilation
With big alignments, sctk needs to be compiled in 64 bits.
By default, the C/C++ software are compiled in 32 bits with the options (-Os)
but can be compiled in 64 bits, -m64 is added to the CFLAGS variable in:
src/asclite/core/makefile
src/asclite/test/makefile
src/rfilter1/makefile
src/sclite/makefile
Example of CFLAGS:
For OSX 10.4+: -fast -m64 -arch x86_64 -arch ppc64
So, I went to the makefiles listed (except rfilter1, see below) and changed the code there, replacing each -Os with -m64. Do this ONLY for the makefiles that are listed. I'll give an example for one of the listed files, but note you will have to do it for the others.
cd sctk
vim src/asclite/core/makefile
When the file was open, I found the line:
CFLAGS = -g -Os
which I changed to
CFLAGS = -g -m64
(pressed "i" to get into INSERT mode, made the change, pressed "Esc", then pressed ":wq" (Write and Quit) followed by "Enter")
I made the changes in all the listed files EXCEPT src/rfilter1/makefile, because that file had no -Os in it. This ended up being important, as the install wouldn't work if I had changed this file at all.
After this was completed, I ran make clean, but I DID NOT run make config, because this would have undone the changes we just make. I went directly to:
make all
This gets us past where we were before.
This problem was taken care of, but there was another problem:
In file included from main.cpp:20:0:
recording.h:122:36: error: template argument 2 is invalid
map<string, Filter::Filter*> filters;
^
recording.h:122:36: error: template argument 4 is invalid
which I asked about here.
AN EVEN EASIER SOLUTION - Taking advantage of a new, edited version of sclite
This is in case someone finds the answer here useful. I know there are no votes here, but I just got a trophy telling me this is my first question to get 1000 views, so I'll update my answer to show the easiest way to get things done.
TL;DR
https://www.nist.gov/itl/iad/mig/tools
https://github.com/usnistgov/SCTK
% cd /the/dir/where/i/want/to/install
% git clone https://github.com/usnistgov/SCTK.git
% cd SCTK
From the git master README (quoted) with some comments I've put in.
% make config
% sed -i 's#[-]Os#-m64#g' src/asclite/core/makefile
% sed -i 's#[-]Os#-m64#g' src/asclite/test/makefile
% sed -i 's#[-]Os#-m64#g' src/sclite/makefile
% make clean
% ## Possible edit to the `rfilter1 makefile`, which are
% ## described at the end of the answer but were not necessary
% ## for me.
% make all
% make check
% make install
% make doc
I also add the executables' directory to my PATH and make the documentation available via the man command.
% pwd
/the/dir/where/i/want/to/install/SCTK
% # back up your `.bashrc`
% cp $HOME/.bashrc "${HOME}/.bashrc.$(date +%Y%m%d-%H%M%S).bak"
% # persistent path changes
% echo -e "\n\n## Allow access to sclite, rfilter, etc" >> $HOME/.bashrc
% # your machine might use something other than `export` for this. CHECK!
% echo 'export PATH='"$(pwd)/bin"':$PATH' >> $HOME/.bashrc
% # make changes availabel this session
% source ~/.bashrc
% # man stuff
% cd doc
% cp -r ./* /usr/man/man1
END OF THE TL;DR SECTION
Details
Since when I posted this in May 2018, there have finally been some updates made to the software:
I posted my question in May 2018, and the updates were made in Fall 2018. They partly fix the problems I ran into here, but some of the information in the README and some makefiles are useful to note here.
The 32- to 64- bit issue (changing -Os to -m64, as done above) was find-able via the README.
% cat -n README.md | grep -A 4 "64 bits Compilation"
61 **64 bits Compilation**:
62 With big alignments, sctk needs to be compiled in 64 bits. By default, the C/C++ software are compiled in 32 bits with the options (`-Os`) but can be compiled in 64 bits. To do so, `-m64` is added to the CFLAGS variable in `src/asclite/core/makefile`, `src/asclite/test/makefile`, `src/rfilter1/makefile` and `src/sclite/makefile`.
63
64 Example of `CFLAGS` for OSX 10.4+: `-fast -m64 -arch x86_64 -arch ppc64`
65
Here is line 62 with word wrap
With big alignments, sctk needs to be compiled in 64 bits. By default, the C/C++ software are compiled in 32 bits with the options (-Os) but can be compiled in 64 bits. To do so, -m64 is added to the CFLAGS variable in
src/asclite/core/makefile,
src/asclite/test/makefile,
src/rfilter1/makefile and
src/sclite/makefile.
Since there was no -Os in src/rfilter1/makefile, I didn't make any changes.
I was able to finish the installation with no problem (including no failed tests). Here is my system info.
$ uname -a
CYGWIN_NT-10.0 MyMachine 3.0.7(0.338/5/3) 2019-04-30 18:08 x86_64 Cygwin
$ bash --version | head -n 1
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
$ gcc --version | head -n 1
gcc (GCC) 7.4.0
$ g++ --version | head -n 1
g++ (GCC) 7.4.0
$ make --version | head -n 2
GNU Make 4.2.1
Built for x86_64-unknown-cygwin
$ systeminfo | sed -n 's/^OS\ *//p'
Name: Microsoft Windows 10 Enterprise
Version: 10.0.17134 N/A Build 17134
Manufacturer: Microsoft Corporation
Configuration: Member Workstation
Build Type: Multiprocessor Free
However, it seems that some other people trying to compile on Cygwin have had issues. Here is some more info from the README
% grep "Special Note to Cygwin users" README.md
*Special Note to Cygwin users:* it has been reported that compilation of `rfilter1` can fail in some case, please read the OPTIONS part of the `rfilter1/makefile` and adapt accordingly before retrying compilation.
Well, let's look at the makefile for rfilter1, and see what some of you might need to do.
% head -n 15 src/rfilter1/makefile | tail -7
########################### Options for compilation #########################
####### If you have an very new version of GCC, the strcmp* family of functions
####### is included in the distribution. Changing the value of OPTIONS to
####### be blank will diable the use of supplied versions of these functions.
####### In particular, this behavior has been noted on some versions of cygwin
OPTIONS=-DNEED_STRCMP=1 $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)
So, if you have rfilter1 compilation problems, change the non-commented line to
OPTIONS= $(CPPFLAGS) $(CFLAGS) $(LDFLAGS)
I'm somehow trying to use _CoqProject parser from coq's library in OCaml (I'd welcome better alternatives to grab the .v files of a coq project if that library is not meant for external use, is it?), but ocamlbuild seems to be linking libraries in the wrong order.
Consider this minimal example file
open CoqProject_file
let x = read_project_file
The coq.lib package (bundled with coq) somehow depends on threads, and following this answer suggests to use -tag thread for that, but I still get the following error that threads is not found when linking coq.lib:
$ ocamlbuild -pkg coq.lib -tag thread -cflag -rectypes a.native /tmp/p
+ /home/sam/.opam/4.06.0+coq-8.7/bin/ocamlopt.opt -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/config -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib -I /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/str.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/unix.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa -thread threads.cmxa a.cmx -o a.native
File "_none_", line 1:
Error: No implementations provided for the following modules:
Thread referenced from /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa(Exninfo)
Mutex referenced from /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa(Exninfo)
Command exited with code 2.
Yet that compiles if I take the ocamlopt invocation apart and put -thread threads.cmxa before clib.cmxa
$ cd _build/
$ /home/sam/.opam/4.06.0+coq-8.7/bin/ocamlopt.opt -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/config -I /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib -I /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/str.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/ocaml/unix.cmxa -thread threads.cmxa /home/sam/.opam/4.06.0+coq-8.7/lib/coq/lib/clib.cmxa a.cmx -o a.native
What is the right way to call ocamlbuild?
If you use ocamlfind packages, you should use the -use-ocamlfind flag.
There is no good solution as to why -tag thread is needed¹. There are two different implementations of the OCaml Threads interface (one with os threads and one with green threads), and coq.lib depends on the interface but won't decide for the user which one to use, so you have to specify it manually, for example by using -tag thread.
¹: one solution would be to remove this choice by deprecating vmthreads (the green threads), which is rarely used in practice.
I downloaded and built gcc 4.8.1 on my desktop, running 64-bit Ubuntu 12.04. I built it out of source, like the docs recommend, and with the commands
../../gcc-4.8.1/configure --prefix=$HOME --program-suffix=-4.8
make
make -k check
make install
It seemed to pass all the tests, and I installed everything into my home directory w/ the suffix -4.8 to distinguish from the system gcc, which is version 4.6.3.
Unfortunately when I compile c++ programs using g++-4.8 it links to the system libc and libstdc++ rather than the newer ones compiled from gcc-4.8.1. I downloaded and built gcc 4.8 because I wanted to play around with the new C++11 features in the standard library, so this behaviour is definitely not what I wanted. What can I do to get gcc-4.8 to automatically link to the standard libraries that came with it rather than the system standard libraries?
When you link with your own gcc you need to add an extra run-time linker search path(s) with -Wl,-rpath,$(PREFIX)/lib64 so that at run-time it finds the shared libraries corresponding to your gcc.
I normally create a wrapper named gcc and g++ in the same directory as gcc-4.8 and g++-4.8 which I invoke instead of gcc-4.8 and g++-4.8, as prescribed in Dynamic linker is unable to find GCC libraries:
#!/bin/bash
exec ${0}SUFFIX -Wl,-rpath,PREFIX/lib64 "$#"
When installing SUFFIX and PREFIX should be replaced with what was passed to configure:
cd ${PREFIX}/bin && rm -f gcc g++ c++ gfortran
sed -e 's#PREFIX#${PREFIX}#g' -e 's#SUFFIX#${SUFFIX}#g' gcc-wrapper.sh > ${PREFIX}/bin/gcc
chmod +x ${PREFIX}/bin/gcc
cd ${PREFIX}/bin && ln gcc g++ && ln gcc c++ && ln gcc gfortran
(gcc-wrapper.sh is that bash snippet).
The above solution does not work with some versions of libtool because g++ -Wl,... -v assumes linking mode and fails with an error.
A better solution is to use specs file. Once gcc/g++ is built, invoke the following command to make gcc/g++ add -rpath to the linker command line (replace ${PREFIX}/lib64 as necessary):
g++ -dumpspecs | awk '/^\*link:/ { print; getline; print "-rpath=${PREFIX}/lib64", $0; next } { print }' > $(dirname $(g++ -print-libgcc-file-name))/specs
I just had the same problem when building gcc-4.8.2. I don't have root access on that machine and therefore need to install to my home directory. It took several attempts before I figured out the magic required to get this to work so I will reproduce it here so other people will have an easier time. These are the commands that I used to configure gcc:
prefix=/user/grc/packages
export LDFLAGS=-Wl,-rpath,$prefix/lib
export LD_RUN_PATH=$prefix/lib
export LD_LIBRARY_PATH=$prefix/lib
../../src/gmp-4.3.2/configure --prefix=$prefix
../../src/mpfr-2.4.2/configure --prefix=$prefix
../../src/mpc-0.8.1/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix
../../src/gcc-4.8.2/configure --prefix=$prefix --with-mpfr=$prefix --with-gmp=$prefix --with-mpc=$prefix --enable-languages=c,c++
That got me a working binary but any program I built with that version of g++ wouldn't run correctly unless I built it with the -Wl,-rpath,$prefix/lib64 option. It is possible to get g++ to automatically add that option by providing a specs file. If you run
strace g++ 2>&1 | grep specs
you can see which directories it checks for a specs file. In my case it was $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/specs so I ran g++ -dumpspecs to create a new specs file:
cd $prefix/lib/gcc/x86_64-unknown-linux-gnu/4.8.2
$prefix/bin/g++ -dumpspecs > xx
mv xx specs
and then edited that file to provide the -rpath option. Search for the lines like this:
*link_libgcc:
%D
and edit to add the rpath option:
*link_libgcc:
%D -rpath /user/grc/packages/lib/%M
The %M expands to either ../lib or ../lib64 depending on whether you are building a 32-bit or a 64-bit executable.
Note that when I tried this same trick on an older gcc-4.7 build it didn't work because it didn't expand the %M. For older versions you can remove the %M and just hardcode lib or lib64 but that is only a viable solution if you only ever build 32-bit executables (with lib) or only ever build 64-bit executables (with lib64).
gcc -print-search-dirs will tell you where your compiler is looking for runtime libraries, etc. You can override this with the -B<prefix> option.
I want to combine BOLT, SEXP and ocamlViz for a large project. The problem is, that SEXP and BOLT are using CamlP4 and ocamlviz is using camlp5. But how could I combine the calls to one chain for the -pp argument of ocamlc/ocamlopt?
Here is my call for actual project without ocamlviz:
ocamlopt.opt -c -I +dynlink -I +bolt -I +threads -I +lablgtk2 -I +extlib -I +pcre -I +netsys -I +netstring -I +json-wheel -I +num -I +nums -I +sexplib -I +zip -I +xml-light -I +xmlrpc-light -I +equeue -I +netclient -g -annot -p -thread -pp 'camlp4o /usr/lib/ocaml/bolt/bolt_pp.cmo -logger '\''foo.native'\'' -level DEBUG -- -I /usr/lib/ocaml/sexplib -I /usr/lib/ocaml/type-conv pa_type_conv.cmo pa_sexp_conv.cmo' -o foo.cmx foo.ml
It is impossible to preprocess source file by two different preprocessors simultaneously for obvious reasons, and using one after another is also impossible because the first one will not recognize the syntax intended for the second one. The solution is either to use different syntaxes in different source files or port ocamlviz to camlp4.
If you pass -printer OCaml to Camlp4, it will output the pre-processed O'Caml file in source format. You can then parse this file again with Camlp5 in another step.