I'm trying to build R.3.3.2 on a SuSE Linux server. It is a routine configure/make/install kind of setup.
It relies on some libs/headers that are either missing on my server or are older than required versions. As I run ./configure I get messages like:
configure: error: "liblzma library and headers are required"
I can download and build the missing packages in my home dir (with --prefix=$HOME/packages) as there is enough guidance on R website, but will appreciate guidance in how to build the final target (i.e., R).
If I build with packages installed in my home dir (by updating LD_LIBRARY_PATH) then everyone has to include my packages/ to their paths.
OTOH I am reluctant to add all these new packages to /usr/lib64/ because I am unsure version change impact on other programs. My search path shows:
$ gcc -Xlinker --verbose 2>/dev/null | grep SEAR | sed -e 's/SEARCH_DIR//g'
("/usr/x86_64-suse-linux/lib64"); ("/usr/lib64"); ("/usr/local/lib64"); ("/lib64"); ("/usr/x86_64-suse-linux/lib"); ("/usr/local/lib"); ("/lib"); ("/usr/lib");
which shows that a standard lib version is going to be picked before /usr/local/lib64
So my question is how does one generally resolve this kind of issue?
It also made me think perhaps I should static link only these new packages. Maybe it's a wrong kind of thought :| but I am also unclear what command line options for ./configure to do this. I will appreciate your help. Thanks a lot.
It is checking for dependencies so we need to install
the xz-5.2.2.tar.gz file first which you will get from this site:
http://tukaani.org/xz
Then go to Download Directory and execute these commands
tar xzvf xz-5.2.2.tar.gz
cd xz-5.2.2
./configure --prefix=$HOME/packages
make -j3
make install
Hope it will work for further any help please post your queries with proper error snapshot
Related
I am trying to install the GCC 4.7 in linux environment; using following command:
zypper install *.rpm
in a directory containing:
libgcc_s1-4.7.2_20130108-0.17.2.x86_64.rpm
libmpc2-0.8.2-1.7.1.x86_64.rpm
libstdc++6-4.7.2_20130108-0.17.2.x86_64.rpm
Following error shows up:
error: Failed to read /usr/lib/rpm/rpmrc: Is a directory.
Repository named '_tmpRPMcache_' already exists. Please use another alias.
I am not able to find the tmpRPMcache where it is located so that I I try to find the issue. Any help is highly appreciable.
It seems that - when installing rpm files not from a repository - zypper uses a "temporary" repository for those rpms. For some reason that repository already exists. Probably you can find that file in /etc/zypp/repos.d/ and remove it safely (make a copy just to be sure):
mv /etc/zypp/repos.d/_tpmTPMcache_.repo{,.bak}
(I'm not 100% sure of the exact filename; but I suspect you will find it there.)
I've created packages previously by using a Makefile, the command "dh_make --createorig", then adjusting files in the debian folder generated and finally using the debuild command to generate the .deb. That workflow is simple and works for me, but I was told to adjust it a little in a way that you could build the project from the sources without requiring the orig files and I'm unsure how to do it, but according to this (https://askubuntu.com/questions/17508/how-to-have-debian-packaging-generate-two-packages-given-an-upstream-source-arch) and this structure (http://bazaar.launchpad.net/~andrewsomething/imagination/debian/files) there must be a way. In my case I would have a folder with the sources and all of that and then a debian folder (generated with dh_make) but I'm unsure on how to avoid the debuild command to ask for the .orig files or if I should be using some other command for this.
Sorry for the superlong question, I think I provided all the relevant information, but I can clarify if anything is fuzzy.
The difference is in the version number in the file debian/changelog.
If you use 1.2.3-1 it implied Debian build 1 of an upstream package 1.2.3 --- for which the build programs (dpkg-buildpackage and whichever wrappers on top) --- assume an .orig.tar.gz to exists.
But if you use 1.2.3 it will consider the package 'Debian native' and the archive is just a .tar.gz and not an .orig.tar.gz.
Now the choice should not be driven by your convenience alone. If this has an upstream source, use the first scheme. If not, the second can be fine. In the packages I maintain I have both but way more of the former.
If you want to create a Debian directory directly in the source package (ie you're packaging your own work, rather than from an upstream release) you could use the --native option to dh_make
I think the question was asked differently, it was somewhat clear that the project was upstream and it's probably not a good reason to change its format to native.
Currently I package some upstream python project, this exact same question came to my mind. Why isn't there any dh_* hook to overwrite in order to generate this origin tarball on the fly so you do not get bothered by:
This package has a Debian revision number but there does not seem to be
an appropriate original tar file or .orig directory in the parent directory;
for a start, I added a makefile to the project:
# Makefile
VERSION:=$(shell dpkg-parsechangelog -S Version | sed -rne 's,([^-\+]+)+(\+dfsg)*.*,\1,p'i)
UPSTREAM_PACKAGE:=click_${VERSION}.orig.tar.gz
dpkg:
tar cafv ../${UPSTREAM_PACKAGE} . --exclude debian --exclude .git
debuild -uc -us
clean:
rm -f ../${UPSTREAM_PACKAGE}
debuild clean
so a simple make clean dpkg was all it needed to build the package.
Now I think the question remains if someone has some bright idea how to insert the tar operation within the debian/rules so I could just call debuild -uc -us and it magically creates the orig tarball I would be awsome :)
I'm starting to work with llvm infrastructure, and i'm interested in the use of the debugger tool lldb instead of default gdb. I followed the tutorial of installation of clang (Linux System, through svn options) and now wanted to know if is possible to install lldb only, instead of rebuild the whole structure of llvm. I don't found a especific documentation for that and i don't know any especific forum for llvm, so if anyone know some forum of llvm,
Sorry about my english, i'm a brazilian developer.
I actually found the solution yesterday, but was not sure how the policies to answer your own questions work here, but according to this it's allright. :)
In fact, it is quite simple.
First, you must identify the directory 'src-root' of the installation of the tools llvm/clang using the command 'llvm-config':
llvm-config --src-root
Once you find the directory, you must navigate to the path $src-root/tools and checkout the lldb:
svn co http://llvm.org/svn/llvm-project/lldb/trunk lldb
The next step is go to the build directory, if the steps of the tutorial has been followed, is just necessary to clean the build directory:
rm -rf *
Now, is the step of building the lldb, I personally have used the autoconf options (classical configure make && make install), but cmake can be used as well. When the configure script runs, the binaries of llvm and clang already installed will be detected, avoiding rebuild the whole structure of llvm/clang.
The parameters of the configure script can be changed, I use as follow because I intend to use the llvm libraries:
../llvm/configure --enable-optimized --enable-assertions --enable-shared --enable-targets=host
Then:
make -j4
sudo make install
where -j4 option is the number of threads (jobs) to be created.
Reference: http://www.felixmorgner.ch/en/blog/building-clang-lldb-and-libc-on-ubuntu/
Created a simple debian/ubuntu package with some library files (*.so).
Works fine except, it installs them as default in the root path "/".
Since I've recreated my Makefile to output to $DESTDIR/ instead of "the usual" directory that I provide in the Makefile, when compiling from source, how do I now set the path of where the files should be installed now? I know there are several choices when using dh_make to create the package, "s" being the default one. Still, can't seem to find anything on where to tell dpkg to put the installed files.
Secondly, a Deb Library package containing only ".so" files should still be a "Single binary" since I gather that using the Library is for development purposes? Since this is a library, I just wanna make sure that's not the cause of the files being installed in the wrong location. What I mean is .so files and header files installation?
What I've used:
dh_make -e my#email.com -f ../myfile-1.0.tar.gz
dpkg-buildpackage -rfakeroot
and some configurations set i debian/control, $DESTDIR in Makefile.
Seems that it was fairly simple, yet very confusing. This works, not sure if there is a better solution.
In my makefile I have a few variables
InstallTo = /usr/lib
install:
mkdir -p $(DESTDIR)$(InstallTo)
cp $FILE_TO_COPY $(DESTDIR)$(InstallTo)
This way it will create the directory tree inside the *.deb file. I had some trouble using /usr/local/lib instead of /usr/lib/ and rmdir complained when trying to delete it and it had no files (just directories). Not sure why, but changed it to /usr/lib instead.
Since someone voted this up, I'm guessing someone were also looking for the answer and this is my solution. Perhaps someone can provide a better one if there is one.
Just a note, $DESTDIR variable is the variable that dh_make suggest the user to use in our Makefile. It's the path to where dpkg will build the program and where it will install it so it can be included in the .deb file.
I have a debian package that I built that contains a tar ball of the files, a control file, and a postinst file. Its built using dpkg-deb and it installs properly using dpkg.
The modification I would like to make is to have the installation directory of the files be determined at runtime based on an environment variable that will be set when dpkg -i is run on the deb file. I echo out the environment variable in the postinst script and I can see that its set properly.
My questions:
1) Is it possible to dynamically determine the installation directory at runtime?
2) If its possible how would I go about this? I have read about the rules file and the mypackage.install files but I don't know if either of these would allow me to accomplish this.
I could hack it by copying the files to the target location in the posinst script but I would prefer to do it the right way if possible.
Thanks in advance!
So this is what I found out about this problem over the past couple of weeks.
With prepackaged binaries you can't build a debian package with a destination directory dynamicall determined at runtime. I believe that this might be possible if installing a package that is built from source where you can set the install directory using configure. But in this case since these are embedded Ubuntu machines they don't have make so I didn't pursue such an option. I did work out a non traditional method (hack) for installing that did work. Since debian packages simply contain a tar ball relative to / simply build your package relative to a directory under /tmp. In the postinst script you can then determine where to copy the files from the archive into a permanent location.
I expected that after rebooting and the automatic deletion of the subdirectory under /tmp that dpkg might not know that the file package existed. This wasn't a problem. When I ran 'dpkg -l myapp' it showed as still installed. Updating the package using dpkg/apt-get also worked without a hitch.
What I did find is that if you attempted to remove the package using 'dpkg -r myapp' that dpkg would try and remove /tmp which wasn't good. However /tmp isn't easily removed so it never succeeded. Plus in our situation we never remove packages but instead simply upgrade them.
I eventually had to abandon the universal package due to code differences in the sources resulting in having to recompile per platform but I would have left it this way and it did work.
I tried using --instdir to change the install directory of the package and it does relocate the files but dpkg fails since the dpkg file can't be found relative to the new instdir. Using --instdir is sort of like a chroot. I also tried --admindir and --root in various combinations to see if I could use the dpkg system relative to / but install relocate the files but they didn't work. I guess rpm has a relocate option that works but not Ubuntu.
You can also write a script that runs dpkg-deb with a different environment for 6 times, generating 6 different packages. When you make a modification, you simply have to run your script, and all 6 packages gets generated and you can install them on your machines avoiding postinst hacking!
Why not install to a standard location, and simply use a postinst script to create symbolic links to the desired location? This is much cleaner, and shouldn't break anything in dpk -I.