I need a non-stripped version of libpthread.so for debugging. How can I compile it from source code? Host is Linux 2.6.
If you're on an RPM based system, use rpm -qf .../libpthread.so to find out which package installed the file (if that doesn't produce a result, the .so file is probably a link; then run the command on the file the link points to).
If you have the package name, search for the "source package". How this works depends on the distribution you use. For openSUSE, you must add the Source Repository using Yast. After that, you can install the source package which will give you some entries under /usr/src/packages. To build the package, go to /usr/src/packages/SPECS and run rpmbuild with the pthread.spec file as parameter.
When the build suceeds, edit the .spec file and change it so it doesn't strip the symbols.
Alternatively, look if there is a *-debug package (replace "*" with the name of the package) and install that. It should contain the version of the library with the symbols.
Related
I have CMake project built and installed.
Now I want to generate debian package (*.deb) from this. In the Internet there are many instructions how to create debian package with adding something to CMake's files, but the project, which I've built does not belongs to me, so I shouldn't modify its source.
I've found command cpack, which is can also generate deb packages. Unfortunately when I try to use the command:
cpack -G DEB -C cmake/build/directory -P myPackage.deb -R 1.0.
I see:
CPack Error: Please specify build tree of the project that uses CMake using CPACK_INSTALL_CMAKE_PROJECTS, specify CPACK_INSTALL_COMMANDS, CPACK_INSTALL_SCRIPT, or CPACK_INSTALLED_DIRECTORIES.
Unfortunately the options can't be specified in commands in help:
cpack --help
So is it possible to generate debian package with command cpack without any changes to CMake files?
When the CMakeLists.txt includes the CPack module, it produces CPackConfig.cmake in the top build directory. This config file is the default for CPack, but you can override it w/ --config option.
The file consists of a bunch of set() commands to set various CPACK_* variables. To produce a package (the DEB in your question) you ought to write the config file "manually" and set vital variables for CPack, as well as some for DEB generator (i.e. CPACK_DEBIAN_*).
Generally, this config (the variables in it) describes what project(s) and it's components to include to package(s), define some meta-data & so on... In theory, you can pass all that defines via -D options to cpack(1). In practice, IMHO, it'll be easier to write the CPackConfig.cmake %)
Having that config file this command should to what you want:
$ cpack -G DEB
(or just cpack alone if your config describes only Debian package to build).
I have some task to make linux's bootable image with my own package. This package (named starlet) is a set of .C modules + Makefile. I created the package/starlet directory and added Config.in and starlet.mk; selected in the Buildroot configuration to include my package to build target image.
So, it's works fine...
Now i'm need to build starlet's image with additional library from the zztop-dev package.
zztop-dev package is an .RPM package with set of .H and .C files to build target zztop.a (.so) libraries.
What do I need to do to install zztop-dev.RPM before building STARLET image?
Having the source code for a package stored in a .rpm file is quite uncommon. Buildroot has built-in rules to extract all the most common formats. Using an uncommon format requires you to write extraction rules on your own.
So the first question is whether you can use a more common format that Buildroot has rules for. You probably can access the source code from its original location in a source code repository (git, Subversion, whatever) or a tarball.
If you really need to extract the sources from am .rpm file, then you need to write your own custom extract commands. Look for LIBFOO_EXTRACT_CMDS in the Buildroot user manual.
But if your extract commands call the rpm command to do the extraction then you'll need the rpm tool either installed on your host machine, or packaged as a host package in Buildroot and listed as a dependency of zztop-dev. The former approach is way simpler, but it will force you to have rpm installed on every host machine where you run the build.
I just installed Cmake from git clone wget http://www.cmake.org/files/v2.8/cmake-2.8.3.tar.gz in a new folder on a Linux server. The compilation worked but cmake command is not recognized from other paths. Should I copy the entire contents of cmake-2.8.0 folder to usr/local/bin? Or is the contents of bin folder that need to be copied?
Thanks
On Linux and other Unix-based systems, a common arrangement is to install packages to /opt and add relevant entries to the PATH environment variable to make them available. This is intended for packages not provided by the native package manager or distribution. By choosing an appropriate directory structure, this can be done in a way which also allows different versions to be installed simultaneously and the user can pick which one they want by adding the relevant directory to the PATH.
For the specific case of CMake asked about in the question, you can use a directory structure like /opt/cmake/<version> and then add the relevant /opt/cmake/<version>/bin directory to your PATH (e.g. /opt/cmake/3.8.2/bin for the 3.8.2 CMake release). You can even just download the official pre-built CMake tarballs, unpack them and move the top level directory into the /opt/cmake area as the particular version you downloaded. I've used this successfully on Linux, MacOS and Solaris, as I'm sure have many others.
Note that once you've run CMake on a particular source tree, the cmake executable doesn't need to be on the PATH any more. If cmake needs to be re-run, the build will do so itself and it records the full path to the cmake executable in its own cache, so the PATH isn't even consulted (this is essential in ensuring the same version of CMake continues to be used for all builds regardless of the PATH, since PATH can change between login sessions, etc.). You would only need cmake on your PATH if you intend to invoke cmake manually or for the first time you run it on a source tree, but in both of these cases you can always just use the full path to the cmake executable if you preferred.
I should also add that the entire set of files provided in the CMake package are required, not just the bin directory. CMake makes extensive use of files in its other directories, such as the various modules it comes with. If you are building CMake from source, you may want to build the package target so you get a relocatable tarball or similar which will contain everything that should be included when you provide a CMake package on your system.
After the build, use 'sudo make install'. This will make sure the correct libraries and binaries are copied to their proper places.
Usually this will install the binary to /usr/local/bin.
Make sure the PATH variable has this included.
sudo make install did not copy to /usr/local/bin/ for some reason, so I copied the content of CMAKE /bin. to usr/local/bin an it worked.
cp –a bin/. /usr/local/bin/
I have a libfoo-devel rpm that I can create, using the trick to override _topdir. Now I want to build a package "bar" which has a BuildRequires 'libfoo-devel". I can't seem to find the Right Way to get access to the contents of libfoo-devel without having to install it on the build host. How should I be doing it?
EDIT:
My build and target distros are both SuSE.
I prefer solutions that don't require mock, since I believe SuSE does not include it in its stock repo.
Subsequent EDIT:
I believe that the answer I seek is in the build package. Perhaps it's SuSE's answer to mock? Or it's the distributed version of the oBS service?
DESCRIPTION
build is a tool to build SuSE Linux
RPMs in a safe and clean way. build
will install a minimal SuSE Linux as
build system into some directory and
will chroot to this system to compile
the package. This way you don't risk
to corrupt your working system (due to
a broken spec file for example), even
if the package does not use BuildRoot.
build searches the spec file for a
BuildRequires: line; if such a line is
found, all the specified rpms are
installed. Otherwise a selection of
default packages are used. Note that
build doesn't automatically resolve
missing dependencies, so the specified
rpms have to be sufficient for the
build.
Note that if you really don't need libfoo-devel installed to build package bar the most sensible alternative would be to remove libfoo-devel from the BuildRequires directive (and maybe put the requirement where it belongs).
However, if you cannot do that for some reason, create a "development" rpm database. Basically it involves using rpm --initdb --root /path/to/fake/root. Then populate it with all of the "target packages" of your standard distro installation.
That's a lot of rpm --install --root /path/to/fake/root --justdb package-name.rpm commands, but maybe you can figure out a way to copy over your /var/lib/rpm/* database files and use those as a starting point. Once you have the alternative rpm database, you can fake the installation of the libfoo-devel package with a --justdb option. Then you'll be home free on the actual rpm build.
If neither mock nor the openSUSE Build Service are a viable choice then you will have to buckle down and install the package, either directly or in a chroot; the package provides files that the SRPM packager has decided are required to build, and hence is in the BuildRequires tag.
I want to install multiple versions of a package (say libX) from src. The package (libX) uses Autotools to build, so follows the ./configure , make, make install convention. The one installed by default goes to /usr/local/bin and /usr/local/lib and I want to install another version of this in /home/user/libX .
The other problem is that libX is a dependency for another package (say libY) which also uses autotools. How to I make libY point to the version installed in /home/user/libX ? There could be also a possibility that its a system package like ffmpeg and I want to use the latest svn version for my src code and hence build it from src. What do i do in that case ? What is the best practice in this case so that I do not break the system libraries?
I'm using Ubuntu 10.04 and Opensuse 10.3.
You can usually pass the --prefix option to configure to tell it to install the library in a different place. So for a personal version, you can usually run it as:
./configure --prefix=$HOME/usr/libX
and it will install in $HOME/usr/libX/bin, $HOME/usr/libX/lib, $HOME/usr/libX/etc and so on.
If you are building libY from source, the configure script usually uses the pkg-config tool to find out where a package is stored. libX should have included a .pc file in the directory $HOME/usr/libX/lib/pkgconfig which tells configure where to look for headers and library files. You will need to tell the pkg-config tool to look in your directory first.
This is done by setting the PKG_CONFIG_PATH to include your directory first.
When configuring libY, try
PKG_CONFIG_PATH=$HOME/usr/libX/lib/pkgconfig:/usr/local/lib/pkgconfig ./configure
man pkg-config should give details.