I got the code of libwebsockets from https://github.com/warmcat/libwebsockets.git.
And I found that there is a declaration of the function lws_json_dump_vhost in the lws-context-vhost.h file, but I did not found the implementation of lws_json_dump_vhost.
I use the command line "grep -rn -s "lws_json_dump_vhost"" to search under the root directory of libwebsockets, I only found its declaration in the lws-context-vhost.h file.
I compiled libwebsockets.so with cmake and used nm -D libwebsockets.so to view the symbols, but I did not find lws_json_dump_vhost in the symbols.
So where is the implementation of lws_json_dump_vhost in the libwebsockets library and does libwebsockets support the lws_json_dump_vhost function?
I downloaded the version v2.2-stable of libwebsockets and I find the implementation of lws_json_dump_vhost.
I downloaded the master branch code through git clone before, then I use "git checkout -b remote v2.2-stable".But I think it didn't work.
Related
I'm very new to Yesod and I'm having trouble building Yesod statically
so I can deploy to Heroku.
I have changed the default .cabal file to reflect static compilation
if flag(production)
cpp-options: -DPRODUCTION
ghc-options: -Wall -threaded -O2 -static -optl-static
else
ghc-options: -Wall -threaded -O0
And it no longer builds. I get a whole bunch of warnings and then a
slew of undefined references like this:
Linking dist/build/personal-website/personal-website ...
/usr/lib/ghc-7.0.3/libHSrts_thr.a(Linker.thr_o): In function
`internal_dlopen':
Linker.c:(.text+0x407): warning: Using 'dlopen' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/unix-2.4.2.0/libHSunix-2.4.2.0.a(HsUnix.o): In
function `__hsunix_getpwent':
HsUnix.c:(.text+0xa1): warning: Using 'getpwent' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/unix-2.4.2.0/libHSunix-2.4.2.0.a(HsUnix.o): In
function `__hsunix_getpwnam_r':
HsUnix.c:(.text+0xb1): warning: Using 'getpwnam_r' in statically
linked applications requires at runtime the shared libraries from the
glibc version used for linking
/usr/lib/libpq.a(thread.o): In function `pqGetpwuid':
(.text+0x15): warning: Using 'getpwuid_r' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/libpq.a(ip.o): In function `pg_getaddrinfo_all':
(.text+0x31): warning: Using 'getaddrinfo' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__63.o): In function `sD3z_info':
(.text+0xe4): warning: Using 'gethostbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__164.o): In function `sFKc_info':
(.text+0x12d): warning: Using 'getprotobyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/ghc-7.0.3/site-local/network-2.3.0.2/
libHSnetwork-2.3.0.2.a(BSD__155.o): In function `sFDs_info':
(.text+0x4c): warning: Using 'getservbyname' in statically linked
applications requires at runtime the shared libraries from the glibc
version used for linking
/usr/lib/libpq.a(fe-misc.o): In function `pqSocketCheck':
(.text+0xa2d): undefined reference to `SSL_pending'
/usr/lib/libpq.a(fe-secure.o): In function `SSLerrmessage':
(.text+0x31): undefined reference to `ERR_get_error'
/usr/lib/libpq.a(fe-secure.o): In function `SSLerrmessage':
(.text+0x41): undefined reference to `ERR_reason_error_string'
/usr/lib/libpq.a(fe-secure.o): In function `initialize_SSL':
(.text+0x2f8): undefined reference to `SSL_check_private_key'
/usr/lib/libpq.a(fe-secure.o): In function `initialize_SSL':
(.text+0x3c0): undefined reference to `SSL_CTX_load_verify_locations'
(... snip ...)
If I just compile with just -static and without -optl-static
everything builds fine but the application crashes when it tries to
start on Heroku.
2011-12-28T01:20:51+00:00 heroku[web.1]: Starting process with command
`./dist/build/personal-website/personal-website -p 41083`
2011-12-28T01:20:51+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: error while loading shared libraries: libgmp.so.10:
cannot open shared object file: No such file or directory
2011-12-28T01:20:52+00:00 heroku[web.1]: State changed from starting
to crashed
I tried adding libgmp.so.10 to the LD_LIBRARY_PATH as suggested in here
and then got the following error:
2011-12-28T01:31:23+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: /lib/libc.so.6: version `GLIBC_2.14' not found
(required by ./dist/build/personal-website/personal-website)
2011-12-28T01:31:23+00:00 app[web.1]: ./dist/build/personal-website/
personal-website: /lib/libc.so.6: version `GLIBC_2.14' not found
(required by /app/dist/build/personal-website/libgmp.so.10)
2011-12-28T01:31:25+00:00 heroku[web.1]: State changed from starting
to crashed
2011-12-28T01:31:25+00:00 heroku[web.1]: Process exited
It seems that the version of libc that I'm compiling against is
different. I tried also adding libc to the batch of libraries the
same way I did for libgmp but this results in a segmentation fault
when the application starts on the Heroku side.
Everything works fine on my PC. I'm running 64bit archlinux with ghc
7.0.3. The blog post on the official Yesod blog looked pretty easy
but I'm stumped at this point. Anyone have any ideas? If there's a way to get this thing working without building statically I'm open to that too.
EDIT
Per Employed Russians answer I did the following to fix this.
First created a new directory lib under the project directory and copied the missing shared libraries into it. You can get this information by running ldd path/to/executable and heroku run ldd path/to/executable and comparing the output.
I then did heroku config:add LD_LIBRARY_PATH=./lib so when the application is started the dynamic linker will look for libraries in the new lib directory.
Finally I created an ubuntu 11.10 virtual machine and built and deployed to Heroku from there, this has an old enough glibc that it works on the Heroku host.
Edit:
I've since written a tutorial on the Yesod wiki
I have no idea what Yesod is, but I know exactly what each of your other errors means.
First, you should not try to link statically. The warning you get is exactly right: if you link statically, and use one of the routines for which you are getting the warning, then you must arrange to run on a system with exactly the same version of libc.so.6 as the one you used at build time.
Contrary to popular belief, static linking produces less, not more, portable executables on Linux.
Your other (static) link errors are caused by missing libopenssl.a at link time.
But let's assume that you are going to go the "sane" route, and use dynamic linking.
For dynamic linking, Linux (and most other UNIXes) support backward compatibility: an old binary continues to work on newer systems. But they don't support forward compatibility (a binary built on a newer system will generally not run on an older one).
But that's what you are trying to do: you built on a system with glibc-2.14 (or newer), and you are running on a system with glibc-2.13 (or older).
The other thing you need to know is that glibc is composed of some 200+ binaries that must all match exactly. Two key binaries are /lib/ld-linux.so and /lib/libc.so.6 (but there are many more: libpthread.so.0, libnsl.so.1, etc. etc). If some of these binaries came from different versions of glibc, you usually get a crash. And that is exactly what you got, when you tried to place your glibc-2.14 libc.so.6 on the LD_LIBRARY_PATH -- it no longer matches the system /lib/ld-linux.
So what are the solutions? There are several possibilities (in increasing difficulty):
You could copy ld-2.14.so (the target of /lib/ld-linux symlink) to the target system, and invoke it explicitly:
/path/to/ld-2.14.so --library-path <whatever> /path/to/your/executable
This generally works, but can confuse an application that looks at argv[0], and breaks for applications that re-exec themselves.
You could build on an older system.
You could use appgcc (this option has disappeared, see this for description of what it used to be).
You could set up a chroot environment matching the target system, and build inside that chroot.
You could build yourself a Linux-to-olderLinux crosscompiler
You have several issues.
You should not build production binaries on bleeding edge distributions. The libraries on the production system will not be forward compatible.
You should not link glibc statically - it will always at runtime try to load additional libraries. For example cpu-based assembly. That is what your first warnings are about.
The last linker errors look like they are related to a missing openssl library on the command line.
But all in all - downgrade your distribution.
I had similar problems launching to Heroku (which uses glibc-2.11) where I had an application that required glibc-2.14, but I did not have access to the source and could not re-build it. I tried many things and nothing worked.
My workaround was to launch the service on Amazon Elastic Beanstalk and just provide an API interface.
I found the information provided useful as well, I think the various descriptions miss a critical issue I also ran into while forcing an updated version of Vagrant to start working again.
It's the dependency references internal to something like complicated installs, like Yesod to Heroku. Those interanl refences need to be preserved.
This is the script I wrote to make problems go away (at least, hopefully, for a little while):
#!/bin/bash
cd $HOME/
GLIBC_VERSION="2.17"
GLIBC_PREFIX="/usr/glibc/"
VAGRANT_VERSION="2.2.19"
# Install the basic build system utilities.
yum groupinstall -y "Development tools"
yum install -y curl patchelf
# Grab the tarball with the GNU libc source code.
curl -Lfo glibc-${GLIBC_VERSION}.tar.gz "https://ftp.gnu.org/gnu/glibc/glibc-${GLIBC_VERSION}.tar.gz"
echo "a3b2086d5414e602b4b3d5a8792213feb3be664ffc1efe783a829818d3fca37a glibc-${GLIBC_VERSION}.tar.gz" | sha256sum -c || exit 1
# Extract the secrets and get ready to rumble.
tar xzvf glibc-${GLIBC_VERSION}.tar.gz
# The configure script requrires an independent build directory.
mkdir -p glibc-build && cd glibc-build
# Configure glibc with a GLIBC_PREFIX so it doesn't conflict with distro libc files..
../glibc-${GLIBC_VERSION}/configure --prefix="${GLIBC_PREFIX}" --libdir="${GLIBC_PREFIX}/lib" \
--libexecdir="${GLIBC_PREFIX}/lib" --enable-multi-arch
# Compile and then install GNU libc.
make -j8 && make install
# Download and install Vagrant.
curl -Lfo vagrant_${VAGRANT_VERSION}_x86_64.rpm "https://releases.hashicorp.com/vagrant/${VAGRANT_VERSION}/vagrant_${VAGRANT_VERSION}_x86_64.rpm"
echo "990e8d2159032915f21c0f1ccdcbca1a394f7937e06e43dc1dabe605d208dc20 vagrant_${VAGRANT_VERSION}_x86_64.rpm" | sha256sum -c || exit 1
yum install -y vagrant_${VAGRANT_VERSION}_x86_64.rpm
# Patch the binaries and shared libraries inside the Vagrant directory, so they use the new version of GNU libc.
(find /opt/vagrant/ -type f -exec file {} \; )| grep "dynamically linked" | awk -F':' '{print $1}' | while read FILE ; do
patchelf --set-rpath /opt/vagrant/embedded/lib:/opt/vagrant/embedded/lib64:/usr/glibc/lib:/usr/lib64:/lib64:/lib --set-interpreter /usr/glibc/lib/ld-linux-x86-64.so.2 "${FILE}"
done
The script should be pretty easy to understand, and adapt easily to whatever MacGuffin you want to make work, provied you understand it.
The only tricky part is the rpath you pass to patchelf. Upi need to make sure you preserve the search paths, and precedence your software requires. Or you end up fixing one problem only to create another equally frustrating roadblock.
P.S. Don't forget the update the hashes for any file you down. In particular, you need to compile/install a different version of GNU libc, you will need to update that hash to match the version you want to use.
I'm trying to build a small project that uses ffmpeg library to WebAssembly, with use of Emscripten. Before that, I tried it out by transpiling some simple program from C into Wasm and it worked fine, but that time I was not using any additional libraries.
For C++ I'm working with Visual Studio and FFmpeg I linked in project's "Properties" as follows:
all .h header files I placed in "include" catalog and I added it as "Additional Include Directories" in "C/C++" section
all .lib and .dll.a (for example avcodec.lib or libavcodec.dll.a) files I placed in "lib" and added as "Additional Library Directories" in "Linker" section
All includes and the program itself works fine, so now I was trying to prepare a Wasm module with Emscripten with the same same command that I used earlier, but already knowing that is not going to work:
em++ cut_video.cpp -Os -g1 -L lib -I include -s WASM=1 -s FORCE_FILESYSTEM=1 -s ALLOW_MEMORY_GROWTH=1 -s EXPORT_ES6=1 -s MODULARIZE=1 -s "EXPORT_NAME='Editor'" -s "ENVIRONMENT='web'" -s EXPORTED_FUNCTIONS="['_doubler', '_cut_video', '_cut_video1']" -s ERROR_ON_UNDEFINED_SYMBOLS=0 -s ASSERTIONS=1 --bind -o cutter.js
I added the "-I include" parameter which is suppose to be pointing to the same header files, that I mentioned above, and it seems to be fine for Emscripten, because the initial error was solved by it.
Emscripten already found out the problem with functions from ffmpeg library, so I added "ERROR_ON_UNDEFINED_SYMBOLS=0" just to see what will happen when I will add this module to front-end app. Obviously it end up with error "missing function: av_register_all", which is first ffmpeg function within my code.
All explanations that can be helpful I found really unclear for me, because generally I'm not working with C++ or Linux environment, so I'm not fimilliar with Makefile or so.
Is there a way, basing on what I described and how my project was prepared with Visual Studio, to tell the Emscripten to use those pre-build .dll.a or .lib files of FFmpeg for my app? Or how should I modify my project to make it acceptable for Emscripten?
Edit: Since cut_video.cpp file is quite big, maybe it's a better idea to just paste here a link to this file on github instead of the big block of code.
FFmpeg and Emscripten
Build the FFmpeg libs with Emscripten is not an easy task, but you can follow the ffmpeg.wasm tutorials:
Introduction
Build with Emscripten
Read carefully until the end all the tutorial, because there are so many issues that can arise.
Note
I suggest to you to start with the FFmpeg and Emscripten version used in the tutorial and look at the build-ffmpeg.sh script. The script itself export a wasm file with a main function
https://github.com/ffmpegwasm/ffmpeg.wasm-core/blob/85f0e51d9a94447a3b3481c7a4794c2eb9abbfee/wasm/build-scripts/build-ffmpeg.sh#L22
-s EXPORTED_FUNCTIONS="[_main, _proxy_main]" # export main and proxy_main funcs
that is, the main function from fftools/ffmpeg.c. This will help you a lot.
Useful resources
Note that in the Emscripten docs there is a list of C/C++ libraries/project ported to WASM/Javascript, there are some FFmpeg projects see utilities
Happy coding!
the option returns linking error :
emcc: error: undefined exported symbol: "_proxy_main" [-Wundefined] [-Werror]
does the USE_PTHREAD option generate the proxy_main(...) function to abstract the main(...) ?
-s USE_PTHREADS=1 # enable pthreads support
-s PROXY_TO_PTHREAD=1 # detach main() from browser/UI main thread
-s INVOKE_RUN=0 # not to run the main() in the beginning
-s EXIT_RUNTIME=1 # exit runtime after execution
-s EXPORTED_FUNCTIONS="[_main, _proxy_main]" # export main and proxy_main funcs
I'm working through chapter 3 of the tutorial of LLVM,
The given file myocamlbuild.ml is:
open Ocamlbuild_plugin;;
ocaml_lib ~extern:true "llvm";;
ocaml_lib ~extern:true "llvm_analysis";;
flag ["link"; "ocaml"; "g++"] (S[A"-cc"; A"g++"]);;
But I find if I run
ocamlbuild -pkg llvm repl.byte
Error message is: the required module llvm_analysis is unavailable.
What did I do wrong here? Thanks.
You've followed some outdated and probably wrong instructions. If you will install llvm from opam, it will be correctly packaged, and in order to use the llvm_analysis library, you just need to use -pkg llvm.analysis option of the ocamlbuild tool.
So, erase myocamlbuild.ml file, and any other support files, that you've created (e.g., _tags), and compile it as follows
ocamlbuild -pkgs llvm,llvm.analysis repl.byte
or
ocamlbuild -pkgs llvm,llvm.analysis repl.native
Add other llvm subpackages after the comma (no whitespaces).
To get the list of all llvm subpackages use the following command:
ocamlfind list | grep llvm
See also my other answer to your previous questions for the detailed description on how to setup a new project, that uses llvm
Following my earlier question, now I'm getting this error when trying to perform all the same steps from this article, since I've upgraded from Go 1.6.1 to Go 1.7.1 (I cannot go back to Go 1.6.1 because the linker crashes when tries to compile some shared libraries).
What I did:
Installed go in ~/.go/go (this is later referred to as GOROOT).
Compiled libstd.so:
GOROOT=~/.go/go GOPATH=~/tests go install -buildmode=shared -linkshared std
Compiled calc library:
GOROOT=~/.go/go GOPATH=~/tests go install -a -x -buildmode=shared -linkshared calc
Tried to compile app:
GOROOT=~/.go/go GOPATH=~/tests go build -a -x -linkshared -o app cashier
and received this error:
~/.go/go/pkg/tool/linux_amd64/link: cannot implicitly include runtime/cgo in a shared library
I tried to repeat the steps with CGO_ENABLED=0 prepended to the environment, but nothing would build this way. Giving me this error:
imports runtime/cgo: C source files not allowed when not using cgo or SWIG: gcc_fatalf.c gcc_linux_amd64.c gcc_mmap.c gcc_util.c
Is this a known bug? Is making shared libraries meant to be supported?
The only way I've been able to make working DLLs is to use buildmode=c-archive and write C stubs for all the go functions I want to export. But I was working on Windows for this, I haven't had to mess with this on Linux. It is a path to investigate.
I'd like to specify GCC's search directory for the startfile and
endfile: crt1.o, crti.o and crtn.o. Passing -B on the command line to
the GCC driver works, but is inconvenient. How do I modify the specs
file (lib/gcc/x86_64-unknown-linux-gnu/4.9.2/specs) to specify the search path for startfile?
I tried adding the -B option to the startfile spec and got the error:
ld: unrecognized option '-B/gsc/btl/linuxbrew/lib'
I then tried adding the -B option to the cc1 spec and got the error:
cc1: error: command line option '-B/gsc/btl/linuxbrew/lib' is valid
for the driver but not for C
If it's not possible to do this via the specs file, is there an environment variable or a configure option to GCC that accomplishes the same goal?
I've installed a recent version of glibc in my home directory. Everything's working great. I've modified the specs file to link against the new version of glibc, but it's still linking against the old system version in /usr of startfile and endfile.
Here's a the unanswered question on the gcc-help mailing list. Here's a related Linuxbrew bug, gfortran is broken with stand alone Linuxbrew, and a proposed fix, gcc, binutils: link to Cellar instead of system libs.
Thanks,
Shaun
You can use an absolute path in the *startfile: and *endfile: sections in the specs file, instead of the default relative paths. This will override GCC's choice of the default location.
As per https://wiki.debian.org/Multiarch/LibraryPathOverview, gcc will look for startup files such as crt1.o in $(sysroot)/lib, so you can specify the --sysroot option when running gcc, or compile gcc with --with-sysroot.