I recently took over some RPM work while one of our colleagues is away. During the post installation step, the RPM installs some libraries in a particular location, writes a file to /etc/ld.conf.so.d/ containing the path to these files, and then runs "ldconfig". But when the call is made, there are quite few messages stating that: "libXYZ.so* is not a symbolic link".
I looked at the files and the sym links are not set up correctly. E.g., libA.so.1 and libA.so.1.1 are identical files, instead of libA.so.1->libA.so.1.1. Whenever ldconfig is run on a system with the RPM installed, these messages are shown.
Now for no particular reason, I tried replicating this by creating a shared library called libmylib.so.1.1. Then I created another file called libmylib.so.1 which was identical to the previous file. I added a test.conf file to /etc/ld.conf.so.d which contains the path to these shared libraries, and then ran ldconfig. But I didn't see any of these "not a symlink" messages. Instead ldconfig set up two symlinks to both these files. Is that message displayed only under particular circumstances?
Also, when I'm installing shared libraries, do I need to setup the links such as:
linker name -> so name -> real name
manually? And then run ldconfig?
This is my first time working with RPM and installing shared libraries, so any input would be appreciated.
Thanks
Common practice is to make symbolic links to relate the library version and soname to the name used when building/linking a program. Here are a few comments on that:
Program Library HOWTO: 3. Shared Libraries
“soname” option for building shared library
ldconfig expects that there is only one actual file. Here are a few places where this question has been asked:
Always getting “not a symbolic link” message, while installing any package
ldconfig : /usr/lib/libstdc++.so.6 is not a symbolic link + mysql
Usually, problems in this area are due to improper updating of the symbolic links. But an incorrect build-script can be the problem as well.
Related
I wrote a SPEC file to build RPM package. I need to let end user to determine the value of an variable in the %pre section. So I use "read < my_variable >" command in the %pre section. But, when installing, the "read" command seems ignored by system, because the system didn't wait for me to enter the value. Why? and Is there any good method to do the above thing?
Rather than embed the read within your package, RPM has a conditional mechanism which can be used via command-line parameters. Most usage of conditionals in RPMs tests constants defined in the system's RPM macros or making simple filesystem checks. You should investigate those first, because it allows your package to install without help from the person doing the install.
Here are some useful pages discussing RPM conditionals:
Passing conditional parameters into a rpm build (rpm.org)
PackagerDocs/ConditionalBuilds (rpm.org)
Conditionals (Maximum RPM: Taking the Red Hat Package Manager to the Limit)
openSUSE:RPM conditional builds
As one can see from the suggested reading, these are build-time rather than install-time features. You cannot make an "interactive" RPM install. To read more about that, see these pages:
Is it possible to get user's input during installation of rpm?
RPM - Install time parameters
The latter is clear that this is intentional on the part of the developers. As an aside, one response mentions the --relocate option, implying that this solves the problem. However, it is actually different. Read more about that here:
Relocatable packages
Chapter 15. Making a Relocatable Package (Maximum RPM)
I am trying to connect Matlab and OpenCV following this tutorial: http://xanthippi.ceid.upatras.gr/people/evangelidis/matlab_opencv/
Since I work on a Linux system I can't follow the instructions for the mexopts.bat file since the Linux equivalent (mexopts.sh) seems to be rather different and i find none of the options mentioned in the tutorial in the mexopts.sh file.
So I try to set the options in Matlab.
I downloaded the most recent OpenCV Version (2.4.8) and compiled it according to the instructions on their site (http://docs.opencv.org/2.4/doc/tutorials/introduction/linux_install/linux_install.html without the make install).
The structure of the OpenCV directory seems to be a problem, since there are multiple include directories and I was unsure which to specify.
[edit]:
there was a lot of pointless code here which has all been made superfluous as #Peter made me aware that I simply misunderstood how make/make install worked.
"Without the make install" is the problem. The include files and built libraries are scattered all over the source tree, as determined by the build system. make install collects all the headers that are appropriate for use by users of the library and puts them in one directory for including. It does the same with the libraries themselves. make install may also "strip" the libraries, which drastically reduces the size and improves the load time.
If you don't want the installation in a system directory, you can set the install path to be somewhere in your home directory.
I can't load modules that are in same folder in CoqIde.
I'm trying to load sources from Software Foundations, I'm running coqide in folder that contains SF sources with coqide or coqide ./, then after opening and running the file, I'm getting this error:
Error: Cannot find library Poly in loadpath
in this line:
Require Export Poly.
and it's same for every other require commands.
So how are you people loading programs from SF into coqide ?
You need to compile the .v files into .vo files and add their directory to your load path if you're going to require them. To compile them, run coqc <file-path> in the command prompt. To add the files' directory to your load path in CoqIde, you can insert the line Add LoadPath "<directory-path>". at the beginning of the .v files.
I realize this is an old thread, however there are not many resources on this problem. I just spent some time solving it so I figured it would be good to post it on the first topic I got from googling. I'm using Coq 8.4p16 compiled with no additional configuration on Arch Linux.
So, the manual says variables like $COQPATH, ${XDG_DATA_DIRS}/coq/ and ${XDG_DATA_HOME}/coq/ are checked, however I've had no luck with those.
I also tried putting coqc -I /folder/path the Edit->Preferences->Externals of CoqIde, however, still no luck there.
I write these as they may work for someone.
The only GLOBAL way which works for me is writing a coqrc file with Add LoadPath "<directory-path>". in it. On Linux the file needs to be in the home folder.
Hope this saves someone some time.
To be able to load a source file in coqtop, coqc, CoqIDE, or Proof General there are several ways, one method is as follows:
Suppose you have downloaded code files for the book titled Certified Programming with Dependent Types written by Adam Chlipala that are available here and extract them in a path we call CODEHOME. As you can see there are this first line in any source files Require Import Bool Arith List Cpdt.CpdtTactics.
First type coqc -v in a cli (command line interface), the output would be something like The Coq Proof Assistant, version 8.4pl4 ...., then create a file named coqrc.8.4pl4, the file extension should be in accord with the version of the coq you are using, in $HOME/.config/coq directory if it does not exist and write this line in it Add LoadPath "CODEHOME/cpdt/src" as Cpdt . and that's it.
If you started your file.v with Module file. just get rid of it (Also get rid of the End file.) and your problem is solved.
I'm creating a Perl 5 module distribution, the source of which is hosted on github. I've run into the same problem as user Anirvan in this question: I'd like github to see a README.md file, but the .tar.gz to include the same file as plain README. The answer to that question, "use README.pod for both", works in this case, but I'm wondering if I could have made my original attempt work:
I only have README.md in the repository, not README.
My MANIFEST contains README (since that's going into the tarball), but not README.md (since it isn't).
My MANIFEST.SKIP contains README.md, since I don't want that in the tarball.
My Makefile.PL (*) has an entry under PL_FILES to a short script that copies the README.md to a README file
This generates the README, but along the way:
t/manifest.t without make complains that README is in the manifest, but is missing
perl Makefile.PL also complains about README missing
Am I misinterpreting the purpose of the MANIFEST file, or this test? Is it somehow possible to denote a file which should be packed, but isn't there yet? I've tried changing the test, but I could only find a way for Test::CheckManifest to ignore files that were there, but "shouldn't be", not ignore files that are not there, but "should".
(*) Yes, I'm using ExtUtils::MakeMaker, since that's what module-starter defaulted to, and it works so far. I'm not sure if another tool would change much, though.
(Answering my own question here): ExtUtils::MakeMaker, Module::Build and the others are primarily installation methods. You should ignore what make, Build and the others are complaining about while building the distribution. It's what make disttest complains about that matters.
For that matter, do not place code to help build your distribution in Makefile.PL. You should only place code there that is to be run during installation time. So if you want README.md to become README, you had better distribute README.md too. This is obviously not what you want(*).
Instead, take a look at Dist::Zilla. This is explicitly a distribution creation system, and not an installation system.
(*) Replying to your own question can get really wierd… :-/
I am creating rpm for apc. While writing spec file, I realized that some commands may have path which can keep on changing which are required during the compilation time. For eg. these commands are required to be executed during the building time.
$ /usr/local/php/bin/phpize
$ ./configure --with-php-config=/usr/local/php/bin/php-config
But the complete path of phpize and php-config file may change. So how can i prevent this dependencies so that i should not hard-code these path in my spec file.
Because these commands are used at building time, the ideal solution to this problem is here:
Find packages on distribution which provide these commands or paths e.g php-config is provided by php-devel package on Fedora operating system. In fedora you can find it using yum whatprovides "*/php-config" or if they are already installed on system then using rpm -qf /path/to/command.
Once you know the packages add them as BuildRequire tag in spec file. Step 2 will make sure that paths are always present whenever you build the package from spec file even if you use hard coded paths (which isn't ofcourse best way to do it).
In place of /usr/ you can use %{_prefix}, it depends entirely on macros available on distribution you are building this rpm on. Check macro files for path macros. One link which has common macro definitions is here.