I was trying to use idea encryption module in openssl. After installing openssl, while listing cipher commands, IDEA was absent there. The source does contain idea folder in crypto folder. While configuring the following message is displayed in terminal corresponding to configuring idea
making links in crypto/idea...
make[2]: Entering directory `/home/primal/openssl-1.0.0c/crypto/idea'
idea.h => ../../include/openssl/idea.h
ideatest.c => ../../test/ideatest.c
make[2]: Leaving directory `/home/primal/openssl-1.0.0c/crypto/idea'
making links in crypto/bf..
While running make all command I got the following message
making all in crypto/idea...
make[2]: Entering directory `/home/primal/openssl-1.0.0c/crypto/idea'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/primal/openssl-1.0.0c/crypto/idea'
Any help on how to add idea support to openssl would be much appreciated.
Perhaps you can try following the suggestion in this link, which is MAKE_IDEA variable must be set in make.conf.
Related
when compiling R 3.1.0 to install in a partition (NFS format) of a server, I encounter an error as follow.
make[4]: Entering directory `/home/XXX/download/R-3.1.0/src/library/base'
mv: preserving permissions for `all.R': Operation not supported
make[4]: *** [mkRbase] Error 1
Someone suggest it should be related with NFS format. But how to tackle it?
While installing libsigsegv for clisp, I have run into an error. "make install" does not finish correctly. The problem as I can see it is a permission issue. I am very new to Unix and cant figure out how to solve this issue. Can you help me please to solve this issue? Any suggestions highly appreciated.
me#me-VPCSB11FX:~/school/summer/libsigsegv/libsigsegv$ make install
Making install in src
make[1]: Entering directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
make[2]: Entering directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
test -z "/usr/local/lib" || /bin/mkdir -p "/usr/local/lib"
/bin/bash ../libtool --mode=install /usr/bin/install -c 'libsigsegv.la' '/usr/local/lib/libsigsegv.la'
/usr/bin/install -c .libs/libsigsegv.lai /usr/local/lib/libsigsegv.la
/usr/bin/install: cannot create regular file '/usr/local/lib/libsigsegv.la': Permission denied
make[2]: *** [install-libLTLIBRARIES] Error 1
make[2]: Leaving directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
make[1]: *** [install-am] Error 2
make[1]: Leaving directory `/home/me/school/summer/libsigsegv/libsigsegv/src'
make: *** [install-recursive] Error 1
The installation step is trying to write to a shared directory /usr/local/lib, which is read-only for end users and writable only for administrators and such.
You would need to give yourself additional privilleges by using su or sudo -- see e.g. here.
Also please note that installing custom stuff this way of make install is not very nice nowadays. You should be using some package management system like RPM or Aptitude or whatever, depending on your Unix distribution. It handles uninstallation, dependencies, conflicts, updates and everything else automatically.
The detailed installation instructions are found in the INSTALL or INSTALL.generic file, for every GNU package. For GNU libiconv it is this file: http://git.savannah.gnu.org/gitweb/?p=libsigsegv.git;a=blob;f=INSTALL
The default installation location, /usr/local, is not writable by an ordinary user. You have three options:
Use sudo make install instead of make install.
Make the /usr/local directory and its subdirectory owned by yourself, instead of owned by root: chown -R $(id -u -n) /usr/local
Specify a different installation directory (see section "Installation Names" of said INSTALL file): For example: ./configure --prefix=${HOME}/gnu/arch/$(uname -p)
I have installed the pNaCl SDK and have run the command "make serve", as instructed to by the website https://developers.google.com/native-client/dev/devguide/tutorial/tutorial-part1 into my console, it does not run any server and produces the error message:
C:\Users\USERNAME\Documents\nacl_sdk\nacl_sdk\pepper_33\getting_started>make serv
e
C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/tools/make -C part1 all
process_begin: CreateProcess(NULL, python C:/Users/USERNAME/Documents/nacl_sdk/na
cl_sdk/pepper_33/tools/getos.py, ...) failed.
make[1]: Entering directory 'C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper
_33/getting_started/part1'
make[1]: Makefile:27: pipe: No error
C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/toolchain/_pnacl/bin/pnac
l-clang++ -o hello_tutorial.bc hello_tutorial.cc -O2 -IC:/Users/USERNAME/Document
s/nacl_sdk/nacl_sdk/pepper_33/include -LC:/Users/USERNAME/Documents/nacl_sdk/nacl
_sdk/pepper_33/lib/pnacl/Release -lppapi_cpp -lppapi
process_begin: CreateProcess(NULL, C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/
pepper_33/toolchain/_pnacl/bin/pnacl-clang++ -o hello_tutorial.bc hello_tutorial
.cc -O2 -IC:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/include -LC:/Us
ers/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_33/lib/pnacl/Release -lppapi_cpp
-lppapi, ...) failed.
make (e=2): The system cannot find the file specified.
Makefile:50: recipe for target 'hello_tutorial.bc' failed
make[1]: *** [hello_tutorial.bc] Error 2
make[1]: Leaving directory 'C:/Users/USERNAME/Documents/nacl_sdk/nacl_sdk/pepper_
33/getting_started/part1'
Makefile:46: recipe for target 'part1_ALL_TARGET' failed
make: *** [part1_ALL_TARGET] Error 2
My username is inserted in the place of USERNAME.
Any ideas what is going on?
I looks like perhaps python is not present in you PATH? Can you run "python" on the command line? What does "where python" produce?
I'm somewhere surprised since python is required to install the SDK in the first place. I've opened a ticket to handle this failure mode:
https://code.google.com/p/chromium/issues/detail?id=348139
I solved this, had the same issues, what i did was (my setup):
It seems compile script doesn't like paths with spaces, like: "C:\Documents and ...".
Make sure python path is at environment variables. "C:\Python27"
Put nacl_sdk folder in "C:\stationary".
Put custom environment variable NACL_SDK_ROOT to "C:\stationary\nacl_sdk\pepper_34".
There i did immediate variable assignee.
A. "cd C:\stationary\nacl_sdk\pepper_34\getting_started".
B. "set NACL_SDK_ROOT C:\stationary\nacl_sdk\pepper_34". This must point to the pepper version you want to build against,
C. "make serve".
And that's it! Works, compiled!
I have encountered and solved the same issue. using comment on old post. I tried building one of the other examples and they seem to work while the getting started one doesn't.
"You will have a hard time building those ppapi tests. I suggest trying to build one of the examples provided with the SDK. If you really need to build that test (it isn't an example) you will need to use clang (another C/C++ toolchain). However, from a cursory look, those tests aren't actually built in NaCl, nor do they generate a PPAPI plugin. I have never gotten clang working on Windows, but it is apparently possible. See clang.llvm.org/get_started.html for instructions using Visual Studio. I would probably use MinGW instead, but I can't find decent instructions for that. – DRayX Oct 21 '13 at 16:08 "
I am trying to compile the Qt 5 libraries for my RPI, but it always crashes.
These are the guides I have tried to follow:
http://qt-project.org/wiki/RaspberryPi_Beginners_guide
http://qt-project.org/wiki/RaspberryPi
I have downloaded the cross-compiler and sysroot-image according to the guide and pulled the Qt5 sources from the git repo.
After following one of the guides I am now stuck at make.
This is the error I am receiving:
.obj/release-shared/qlibrary_unix.o: In function `QLibraryPrivate::load_sys()':
qlibrary_unix.cpp:(.text+0xf84): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlopen.o): In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlclose.o): In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlsym.o): In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.a(dlerror.o): In function `dlerror':
(.text+0x0): undefined reference to `__dlerror'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libm.a(feholdexcpt.o): In function `feholdexcept':
(.text+0x48): undefined reference to `_dl_hwcap'
/home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libm.a(fesetenv.o): In function `fesetenv':
(.text+0x64): undefined reference to `_dl_hwcap'
collect2: virhe: ld:n paluuarvo oli 1 # collect2: error: ld returnvalue was 1
make[2]: *** [../../lib/libQt5Core.so.5.0.0] Virhe 1 # Error 1
make[2]: Poistutaan hakemistosta "/home/esa/qtonpi/qt5/qtbase/src/corelib" # Leaving directory
make[1]: *** [sub-corelib-make_first] Virhe 2 # Error 2
make[1]: Poistutaan hakemistosta "/home/esa/qtonpi/qt5/qtbase/src" # Leaving directory
make: *** [sub-src-make_first] Virhe 2 # Error 2
Fix the paths of the libraries in your sysroot. Some libraries are symlinks to absolute paths which are broken when placed in your system. Check something like /home/esa/qtonpi/rpi_image/usr/lib/arm-linux-gnueabihf/libdl.so or similar. You should see those are broken symlinks to absolute paths. Fix all of those. In the documents you reported a script for this purpose is provided. Did you run it (https://gitorious.org/cross-compile-tools/cross-compile-tools/blobs/master/fixQualifiedLibraryPaths)?
Try also to check this if you still encounter troubles: I wrote down some notes compiling a recent version from the git for the wheezy image.
An answer for those who tried both the existing answers and they didn't work:
It might happen that the Raspbian image you downloaded doesn't contain symlinks for libdl and libdm in the /usr/lib/ folder.
In that case the fixQualifiedLibraryPaths won't help you as it can't find the symlinks. Copying libdl.so and libm.so might also fail, for example, if you use a flash drive to copy data from your existing Raspberry Pi, it won't copy them as symlinks, but will copy the libraries themselves. However, for the build to succeed, it seems to require symlinks.
I looked at what libdl and libdm in the /usr/lib/ folder of my Raspberry Pi point at
cd /usr/lib/arm-linux-gnueabihf/
ls -l libld.so libm.so
Do the same for the found files until they are no longer symlinks but normal files.
On my system it turned out they are called libdl-2.13.so and libm-2.13.so and reside in /lib/arm-linux-gnueabihf/ instead of /usr/lib/...
Going back to my PC, I found these exact files in the /lib/arm-linux-gnueabihf/ folder (if you don't find them, you can copy them from your Raspberry Pi). So I created symlinks for them in the /usr/lib/arm-linux-gnueabihf/ folder :
sudo ln -s /lib/arm-linux-gnueabihf/libdl-2.13.so /usr/lib/arm-linux-gnueabihf/libdl.so
sudo ln -s /lib/arm-linux-gnueabihf/libm-2.13.so /usr/lib/arm-linux-gnueabihf/libm.so
After this, qtbase was compiled successfully.
(note, that in order to continue to cross-compile from Qt, you have to
keep the image of your SD card mounted on your PC (as described in
the guide), but that's not enough: you have to mount it before
starting Qt Creator)
Try this
ln -s /mnt/raspberry-rootfs/lib/arm-linux-gnueabihf /lib/
Basically it seems that absolute path(s) have been specified when the so files on the Pi were linked (/lib/), and therefore in the /mnt/raspberry-rootfs they are broken.
Linking the Pi's /lib/arm-linux-gnueabihf to the Pc's /lib directory fixes the wrong linking and allows QT to compile. It's a dirty trick but it works.
If you don't have libdl/ libm on the Pi, then you need to stick the SD card back into the Pi, boot and install them. Obviously you will need to create a new image on the PC from the SD Card and mount it on /mnt/raspberry-rootfs
This could be because libdl.so and libm.so are missing from your local rootfs/usr/lib/arm-linux-gnueabihf directory (there are only libdl.a and libm.a). Copying the two files from the Raspberry Pi should make the compilation successful.
instead of fixQualifiedLibraryPaths use:
cd <folder-with-sysroot-subfolder>
wget https://raw.githubusercontent.com/riscv/riscv-poky/master/script/sysroot-relativelinks.py
chmod +x sysroot-relativelinks.py
./sysroot-relativelinks.py sysroot
I am building a custom R installer, following the instruction in "R Installation and Administration" I've installed the latest Rtools212.exe and Inno Setup.
After successfully running tar --no-same-owner -xf R-2.12.1.tar.gz
I've then run make all recommended from R_HOME\src\gnuwin32 and it runs ok until I get the following message:
building package 'base'
cannot create /tmp/R860644: directory nonexistent
mv: cannot stat '/tmp/R860644': No such file or directory
make[3]: ***[mkR] Error 1
make[2]: ***[all] Error 2
make[1]: ***[R] Error 1
make: ***[all] Error 2
After checking the instruction, I thought it was about the environment variable TMPDIR not being set properly. So I tried two options:
create c:\tmp folder
add TMPDIR to the windows environment variable and set the value as c:\DDDD (an existing folder). I then checked the value of TMPDIR in R console by typing Sys.getenv("TMPDIR"), and the change was confirmed.
To my surprise, however, I still got the same error. It looks like: 1. the make commander can not find the default /tmp, which is actually existing; 2. the change of TMPDIR has not been recognized in this occasion, the make commander still try to find the default directory, rather than the changed one.
I also searched online for this problem, and from what I can find, I have done what people had suggested, so now I am stuck.
Can anyone give me some suggestions? Any help appreciated.
Regards,
Shu
well, I just found a solution for my question,
I typed in "set TMPDIR=c:/DDDD" in the command window, and this time no error has been presented.
But I still wonder why my initial tryouts did not work.