I was trying to get an elementary reqwest http-request going like so
extern crate reqwest;
extern crate url;
use url::Url;
fn main() {
let resp = reqwest::get("http://google.com".parse::<Url>().unwrap());
println!("{:?}", resp.unwrap())
}
However, this produces the error
Could not find directory of OpenSSL installation, and this -sys crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it, you can set the OPENSSL_DIR environment variable for the
compilation process.
Make sure you also have the development packages of openssl installed.
For example, libssl-dev on Ubuntu or openssl-devel on Fedora.
...
Well, this was easy enough to fix. One call to sudo apt install libssl-dev and sudo apt install pkg-config and it's working. But I still don't understand what exactly went wrong here. I thought cargo was supposed to take care of dependencies. Why am I now hunting them manually with apt?
reqwest depends on rust-native-tls, which on Linux depends on openssl-sys, which is where this message comes from.
So cargo did do its job, taking care of Rust dependencies.
However, openssl-sys depends on a C library (OpenSSL), at which point cargo stops caring.
Related
I'm trying to build cpp-netlib 0.12.0 stable in Ubuntu 18.04, but when I get to running
$ make -j4
I get a lot of errors, such as:
error: ‘SSL_R_SHORT_READ’ was not declared in this scope
ERR_PACK(ERR_LIB_SSL, 0, SSL_R_SHORT_READ)
Google told me this was because the make variables -DOPENSSL_INCLUDE_DIR and -DOPENSSL_SSL_LIBRARY need to be defined. However, I can't find the directories/libraries I need to set them to. Examples give /usr/lib/openssl-1.0 and /usr/include/openssl-1.0, but I can't find anything like those, even though I have the latest version of openssl installed through apt-get.
My /usr/include directory contains the folder 'openssl', but usr/lib doesn't have even that, only 'openssh', which doesn't appear to contain anything relevant.
How can I fix this?
Fixed by cloning latest version from git repository and building from that.
I'd like to access a dynamic library using FFI features in the Ren-C Rebol branch. I understand this is possible by building with LibFFI support enabled. What steps do I need to take to enable this?
I mainly use OS X for development, though would also like to be able to build it for use with Linux.
(Note: This is probably the kind of information that should be added to the Wiki, as it is not so much a language question but the kind of thing that is subject to change over time. But, answerable, so...)
If you're using the GNU make method to build (where make -f makefile.boot generates a makefile for you) then you should find some lines in there like:
TO_OS_BASE?= TO_OSX
TO_OS_NAME?= TO_OSX_X64
OS_ID?= 0.2.40
BIN_SUFFIX=
RAPI_FLAGS= -D__LP64__ -DENDIAN_LITTLE -DHAS_LL_CONSTS -O1 ...
HOST_FLAGS= -DREB_EXE -D__LP64__ -DENDIAN_LITTLE ...
Modify the RAPI_FLAGS and HOST_FLAGS lines at the beginning to add -DHAVE_LIBFFI_AVAILABLE. That (-D)efines a preprocessor directive to tell the code it's okay to generate calls to FFI, because you have it available for linking later.
Now to tell it where to find include files. There's a line for includes that should look like:
INCL ?= .
I= -I$(INCL) -I$S/include/ -I$S/codecs/ ...
To the tail of that you need to add something that will look like -I/usr/local/opt/libffi/lib/libffi-3.0.13/include, or similar. The actual directory will depend on where you have libffi on your system. On the OSX system I'm looking at, that has two files in it, ffi.h and ffitarget.h.
(Note: I'm afraid I don't know how these files got on this computer. They didn't ship with the OS, so they came from...somewhere. I don't generally develop on OSX--nor for that matter do I use this FFI. You'll have to consult your local FFI-on-OSX website, or perhaps for support contact Atronix Engineering) who added the FFI features to Rebol.)
Then it's necessary to tell it where you have libffi on your system. You'll find a CLIB line that is likely just CLIB= -lm. You'd change this for example to:
CLIB= -L/usr/local/opt/libffi/lib -lm -lffi
-lffi Tells it to look for the ffi (-l)ibrary, and -lxxx means it assumes the name of the library will be libxxx[something]. -L/usr/local/opt/libffi/lib tells it where to look for it. You'll have to figure out where (if anywhere) you have libffi, and if not get it. If you had it, the directory would have contents something like:
libffi-3.0.13
libffi.6.dylib
libffi.a
libffi.dylib
pkgconfig
I mainly use OS X for development, though would also like to be able to build it for use with Linux.
On Linux it's similar but generally much easier to get the library, as easy as sudo apt-get install libffi-dev. Same step for the RFLAGS and CFLAGS, and it should take care of the location automatically... so you can add just -lffi to CLIB.
Old notes from me:
cat steps-for-lib-ffi-osx
Install libfffi via homebrew
brew install libffi
Add /use/include/libffi to the -I in the generated makefile
Add /usr/local/Cellar/libffi/3.0.13/lib/libffi.a to the OBJS in the
generated makefile
The version 3.0.13 may vary
I am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.
What should I use if I want to use less.js locally and have a file automatically recompiled if either this file or an imported file has changed?
lessphp is a LESS compiler written entirely in PHP, making it very easy to run on the server side if you're already using PHP. It was finally just added to Packagist yesterday! You can install it on a project to project basis using composer. Here is an example composer.json file for declaring it as a dependency to your own project:
{
"require": {
"leafo/lessphp": "dev-master"
}
}
You can also use dotless with mono.. if you have mono then run dotless with the -w (watch) option.
You could use watchdog and this script, which I found useful.
To install watchdog, you’ll first need to have the python setup tools installed (apt-get install python-setuptools assuming you’re using Debian or a Debian-based distribution such as Ubuntu).
Then, simply easy_install watchdog. You'll be able to run the lesswatch script once the installation is complete.
I just built Rakudo and Parrot so that I could play with it and get started on learning Perl 6. I downloaded the Perl 6 book and happily typed in the first demo program (the tennis tournament example).
When I try to run the program, I get an error:
Divide by zero
current instr.: '' pc -1 ((unknown file):-1)
I have my perl6 binary in the build directory. I added a scripts directory under the rakudo build directory:
rakudo
|- perl6
\- scripts
|- perlbook_02.01
\- scores
If I try to run even a simple hello world script from my scripts directory I get the same error:
#!/home/daotoad/rakudo/perl6
use v6;
say "Hello nurse!";
However if I run it from the rakudo directory it works.
It sounds like there are some environment variables I need to set, but I am at a lost as to what the are and what values to give them.
Any thoughts?
Update:
I'd rather not install rakudo at this point, I'd rather just run things from the build directory. This will allow me to keep my changes to my system minimal as I try out different Perl6 builds (Rakudo * is out very soon).
The README file encouraged me to think that this was possible:
$ cd rakudo
$ perl Configure.pl --gen-parrot
$ make
This will create a "perl6" or "perl6.exe" executable in the
current (rakudo) directory. Programs can then be run from
the build directory using a command like:
$ ./perl6 hello.pl
Upon rereading, I found a reference to the fact that it is necessary to install rakudo before running scripts outside the build directory:
Once built, Rakudo's make install target will install Rakudo
and its libraries into the Parrot installation that was used to
create it. Until this step is performed, the "perl6" executable
created by make above can only be reliably run from the root of
Rakudo's build directory. After make install is performed,
the installed executable can be run from any directory (as long as
the Parrot installation that was used to create it remains intact).
So it looks like I need to install rakudo to play with Perl 6.
The next question is, where rakudo be installed? README says into the Parrot install used to build.
I used the --gen-parrot option in my build, which looks like it installs into rakudo/parrot-install. So rakudo will be installed into my rakudo\parrot-install?
Reading the Makefile, supports this conclusion. I ran make install, and it did install into parrot_install.
This part of the build/install process is unclear for a newbie to Perl6. I'll see if I can up with a documentation patch to clarify things.
Off the top of my head:
Emphasize running make install before running scripts outside of build. This requirement is currently burried in the middle of a paragraph and can be easily missed by someone skimming the docs (me).
Explicitly state that with --gen-parrot will install perl6 into the parrot_install directory.
Did you run make install in Rakudo?
It's necessary to do it to be able to use Rakudo outside its build directory (and that's why both the README and http://rakudo.org/how-to-get-rakudo tell you to do it.
Don't worry, the default install location is local (in parrot_install/bin/perl inside your rakudo directory).
In response to your update I've now updated the README:
http://github.com/rakudo/rakudo/commit/261eb2ae08fee75a0a0e3935ef64c516e8bc2b98
I hope you find that clearer than before. If you still see room for improvement, please consider submitting a patch to rakudobug#perl.org.