I am trying to use janus. First step, installation.
I followed the instructions here. All is well. However, when I run
configure prefix=/opt/janus
Relevant portions of the output are:
...
checking for TRANSPORTS... yes
checking for MHD... yes
checking for lws_create_vhost in -lwebsockets... no
checking for amqp_error_string2 in -lrabbitmq... no
checking for MQTTAsync_create in -lpaho-mqtt3a... no
checking for PLUGINS... yes
checking for SOFIA... yes
checking for OPUS... yes
checking for OGG... yes
checking for EVENTS... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating html/Makefile
config.status: creating docs/Makefile
config.status: executing depfiles commands
config.status: executing libtool commands
libsrtp version: 1.5.x
SSL/crypto library: OpenSSL
DTLS set-timeout: not available
DataChannels support: no
Recordings post-processor: no
TURN REST API client: yes
Doxygen documentation: no
Transports:
REST (HTTP/HTTPS): yes
WebSockets: no
RabbitMQ: no
MQTT: no
Unix Sockets: yes
Plugins:
Echo Test: yes
Streaming: yes
Video Call: yes
SIP Gateway: yes
Audio Bridge: yes
Video Room: yes
Voice Mail: yes
Record&Play: yes
Text Room: yes
MY PROBLEM IS WITH THE ENTRY WebSockets: no.
I checked in /usr/lib and here are the relevant files there:
/usr/lib/libwebsockets.a /usr/lib/libwebsockets.so
/usr/lib/libwebsockets.so.11 /usr/lib/libwebsockets.so.5
And in /usr/include
/usr/include/libwebsockets.h
So, I think that libwebsockets is installed properly. What needs to be done to get the webSockets transport enabled?
I did look at this too.
Since https://github.com/meetecho/janus-gateway/pull/996
You need libwebsockets >= 2.0.0. Trusty has an old version.
You have to compile it. See the description of janus how to do that.
Related
The build of 'Haunt' ('make' step) fails with the following:
GEN haunt/config.go
./pre-inst-env: line 31: exec: compile: not found
'compile: not found' ?
Guile is in version 2.0.14, Haunt 0.2.4, the mothership CentOS of version 8. The guile-devel package is present. Any ideas?
~~Ps. Should it be theoretically possible to 'make' it on another x86_64 machine, transfer the files and 'make install' inside of the target environment?~~
I ran into the same issue on Lubuntu 18.04. Here's a hack that has worked for me.
A bit of googling lead me to re-check the output of configure:
$ ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
configure: checking for guile 2.2
configure: found guile 2.2
checking for guile-2.2... /usr/bin/guile-2.2
checking for Guile version >= 2.2... 2.2.3
checking for guild-2.2... no
checking for guile-config-2.2... no
checking for guile-tools-2.2... no
checking if (system reader) is available... no
checking if (commonmark) is available... no
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating example/Makefile
config.status: creating website/Makefile
config.status: creating haunt/config.scm
config.status: creating pre-inst-env
config.status: creating test-env
config.status: creating scripts/haunt
The no on lines 14--16 of output seem to be a problem: for whatever reason those packages are not found by configure. However, I could manually set the variables that Makefile uses (after using dpkg to locate the things):
$ export GUILD=/usr/bin/guild
$ export GUILE_CONFIG=/usr/bin
$ ./configure
(...)
checking for guild-2.2... /usr/bin/guild
checking for guile-config-2.2... /usr/bin
(...)
Now make has worked, as did make install, although the latter required sudo in my case. In any case, I am not yet happy with the solution, because the example from the website (in particular the haunt build) does not work yet.
EDIT: On Lubuntu 20.04 LTS the exporting hack was not necessary, although the installation also required sudo. However, the haunt build example still fails. I will update when I know more.
Hi there I was trying to install nrpe in solaris 8. I know that is very old hahah. But when I run ./configure, it shows me this.
./configure
checking for a BSD-compatible install... ./install-sh -c
checking build system type... sparc-sun-solaris2.8
checking host system type... sparc-sun-solaris2.8
checking for gcc...no
checking for cc...no
checking for cc...no
checking for cl...no
configure: error: no aceptable C compiler found in $PATH
There is a way to get this compilers or somenthing like that?
Thanks for support.
When running the configure script for Octave, I do:
./configure CFLAGS="-I/customlibs/pcre/gnu/8.40/include -L/customlibs/pcre/gnu/8.40/lib/" LD_LIBRARY_PATH="/customlibs/pcre/gnu/8.40/lib"
I have also tried:
./configure CFLAGS="-I/customlibs/pcre/gnu/8.40/include" LDFLAGS="-L/customlibs/pcre/gnu/8.40/lib/" LD_LIBRARY_PATH="/customlibs/pcre/gnu/8.40/lib"
Both of these produce the same failure:
checking pcre.h usability... yes
checking pcre.h presence... no
configure: WARNING: pcre.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: pcre.h: proceeding with the compiler's result
checking for pcre.h... yes
checking pcre/pcre.h usability... no
checking pcre/pcre.h presence... no
checking for pcre/pcre.h... no
checking whether pcre.h defines the macros we need... no
configure: error: to build Octave, you must have the PCRE library and header files installed
I'm lost as to how it can find pcre.h but fails to do anything else with it. Am I doing something wrong on my configure line or is pcre broken? If it's my configure line, how do I link against pcre correctly?
For reference, here's the pcre path:
ls /customlibs/pcre/gnu/8.40/
bin
include
lib
share
I was struggling with that for a while as well, but the solution was actually very simple. just use CPPFLAGS rather than CFLAGS for include files:
./configure CPPFLAGS="-I/customlibs/pcre/gnu/8.40/include" LDFLAGS="-L/customlibs/pcre/gnu/8.40/lib/"
There's also no need for LD_LIBRARY_PATH upon configuring.
Trying to build gearman from the gearmand-0.33.tar.gz from Launchpad using bzr, on a Fedora 64 system.
doing the ./configure by tiself, as well as using the "-with-boost=/usr/include" param generates warnings an errors as the configure process can't seem to find/locate the boost header files.
we've removed/reinstalled the boost header files via "yum install boost*" as well
Any pointers will be tried!
Thanks
./configure
.
.
.
checking if more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... yes
checking for Boost headers version >= 1.39.0... yes
checking for Boost's header version... 1_41
checking for the toolset name used by Boost for g++... gcc44 -gcc
checking boost/program_options.hpp usability... no
checking boost/program_options.hpp presence... yes
configure: WARNING: boost/program_options.hpp: present but cannot be compiled
configure: WARNING: boost/program_options.hpp: check for missing prerequisite headers?
configure: WARNING: boost/program_options.hpp: see the Autoconf documentation
configure: WARNING: boost/program_options.hpp: section "Present But Cannot Be Compiled"
configure: WARNING: boost/program_options.hpp: proceeding with the compiler's result
configure: WARNING: ## -------------------------------------------------- ##
configure: WARNING: ## Report this to https://bugs.launchpad.net/gearmand ##
configure: WARNING: ## -------------------------------------------------- ##
checking for boost/program_options.hpp... no
configure: error: cannot find boost/program_options.hpp
Just have dealt with this problem, installed gcc-c++ and that has resolved it
The correct option is probably --with-boost, you should check that with ./configure -h.
Also, check whether the directory /usr/include/boost exists, because that seems to be what it's looking for.
Furthermore, make sure you shouldn't be using --with-boost-include=/usr/include (and maybe also --with-boost-libs (or -lib)).
In my case, using --with-boost=/path/to/root worked, where /path/to/root contains include/boost.
In other words, --with-boost=/path/to/root/include or --with-boost=/path/to/root/include/boost are both wrong.
I also set --with-boost-libdir=/path/to/root/lib64
Got the warning from configure (last line):
checking for getpagesize... yes
checking for working mmap... yes
checking for ftruncate... yes
checking for memcmp... yes
checking for memcpy... yes
checking for memmove... yes
checking for memset... yes
checking whether overlapping arrays are copied correctly... yes
checking the coffee machine... empty - operator may not work as expected
What is it about?
Source is a libelf from debian packages.
PS: From configure.in
AC_CACHE_CHECK([the coffee machine], mr_cv_coffee_machine,
[mr_cv_coffee_machine='empty - operator may not work as expected'])
You forget to switch on the coffee machine or maybe the cable used to operate the machine is broken.
How do you want that all theses script kept working day and night without a good shot of caffeine ?