I have installed gtsam 4 library from : https://bitbucket.org/gtborg/gtsam.git and since I am facing troubles with compilation I want to uninstall it and link to a local version. The problem is that make uninstall does not exist. Is there a way to remove it or at least make the local version be used instead of it.
In CmakeLists.txt I have include_directories and link_directories pointing to the local version but still the gtsam which is installed is the one that is used.
I tried make -n install but the make prints about 700 lines which is difficult to follow and reverse what happened.
I found install_manifest.txt file in build directory. As I read here it contains all the files to be installed. However. I noticed that most of the files are .h and some are .cmake I do not know if just deleting those files will fix the problem or is going to mess it up.
This answer which is not the top one did the trick, it suggested to remove the files specified in the install_manifest.txt file using the following command :
cat install_manifest.txt | xargs echo sudo rm | sh
However, it has to be noted that in the comments, it is said it can be dangerous if the install_manifest had important files, so it is essential to have a look what is written there.
Related
I am starting out with F# and trying to get it to work with Sublime Text 3 with a package, https://github.com/fsharp/sublime-fsharp-package. After installing the package using Package Control, I see F# appear as an available language to use in Sublime Text's bottom bar, and syntax highlighting appears to work more or less, from what I can tell, but the build system for F# fails to appear as it should.
So, trying to fix things, I run "build.sh install" and get an error, "Cannot open assembly '.paket/paket.bootstrapper.exe': No such file or directory." I am sort of stuck. Many thanks for any help.
From the comments you've made, you appear to be a little unfamiliar with the Unix underpinnings of OS X. I'll explain those first, then I'll suggest something for you to try that may fix your problem.
Technically, files or directories whose name starts with . are not "reserved for the system" as you put it; they're hidden. Now, it's true that Finder won't allow you to create files or directories whose name starts with ., because Apple didn't want to have to field all the tech-support calls from people who didn't know about the hidden-files feature: "I named my file ... more important stuff for work and now it's gone! Help!!!" But if you're in the Terminal app, then you can easily create files or directories with . as their first letter: mkdir .foo should work. You won't see it when you do ls, but ls -a (a for "all") will show you all files, including hidden files. And you can also do cd .foo and create files inside the hidden .foo directory -- and while the .foo folder won't show up in Finder, it will be perfectly accessible in the Terminal, and to any F# programs you might write.
So when you say that you cloned https://github.com/fsprojects/Paket but it failed to include the .github and .paket directories, I think you just don't know how to see them. You can't see them in the Finder (well, you can if you jump through a couple of hoops but I don't think it's worth the effort), but you can see them with ls -a. Just open your terminal, run cd /Users/Username/Paket, and then run ls -a and I think you'll see that the .paket and .github directories were indeed created by your git clone command.
So what you should probably try is this:
Go to https://github.com/fsprojects/Paket/releases/latest
Download the paket.bootstrapper.exe and paket.exe files. Put them in /Users/Username/Downloads (or wherever the default OS X Downloads directory is if it's different -- just as long as it's somewhere where you can find them easily).
Open the Terminal app.
Go to the directory where you've unpacked the Sublime Text 3 package. I.e., in the Terminal app, run cd /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master.
Run ls -a and see if there's a .paket directory.
If it does not exist, run mkdir .paket.
Now do cd .paket so you're in the hidden .paket directory under sublime-fsharp-package-master.
Now do ls and see if there's a paket.bootstrapper.exe file.
If it doesn't exist, then copy in the .exe files you downloaded earlier:
cp /Users/Username/Downloads/paket.bootstrapper.exe .
cp /Users/Username/Downloads/paket.exe .
Important: Now do cd .. to go back up to the /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/ directory.
Now instead of running /Users/Username/Library/Application\ Support/Sublime\ Text\ 3/Packages/sublime-fsharp-package-master/build.sh install, try running it as ./build.sh install. (And also try ./build.sh Install, since I'm pretty sure the capital I is necessary).
(BTW, If you're not familiar with the syntax that I used in steps 9, 10 and 11, where I used a single . or two dots .. in commands, those are a long-standing Unix idiom: . means "the current directory", and .. means "the parent directory".)
I just looked at the build.sh script that you've been running, and it seems to assume that you've done a cd into the package's base directory (the sublime-fsharp-package-master directory) before running the script. So that could explain why it was failing: you were running it from a different directory, rather than doing a cd first. Hence why I marked step 10 as important: I think that was the root cause of the problem.
I'll try to explain it as easy as I can. I tried to include and build package "A" in my Yocto image, but package A depends on libftdi and ftdi-eeprom. Now, "ftdi-eeprom" depends on the "libftdi".
In the newer versions of the "libftdi" the tarball also includes the ftdi-eeprom sources too and when you build the libftdi it builds both of the packages. Although because of the way that package "A" is configured I need two different recipes for each of the dependencies.
long story short, I made the two bitbake recipes as best as I could and successfully built "libftdi". Now when I run the "ftdi-eeprom" recipe, it wants to populate some files into the sysroot that are already installed there by libftdi. Here is where the error occurs... duplicates!
Apparently I need to set a SSTATE_DUPWHITELIST variable and declare that these duplicate files are safe to replace the old ones in the image (this overwrite must happen). Can someone please help me with configuring the SSTATE_DUPWHITELIST? I am not that pro working with Yocto.
Errors that I get on screen are uploaded in Dropbox
Thanks in advance!
The answer is to not use SSTATE_DUPWHITELIST for this at all. Instead, in the libftdi recipe's do_install (or do_install_append, if the recipe itself doesn't define its own do_install) you should delete the duplicate files from within ${D} and then they won't get staged and the error won't occur.
I got it to work by using:
SSTATE_DUPWHITELIST = "/"
Dont forget the quotes. Here's my bb excerpt:
SSTATE_DUPWHITELIST = "/"
DEPENDS = ""
do_unpack() {
mkdir -pv ${S}
tar xvf ${DL_DIR}/${FILENAME}.tar -C ${S}
}
do_install() {
install -d -m 755 ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader1.h ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader2.h ${D}${includedir}
install -m 644 ${S}/${MYPATH}/inc/myHeader3.h ${D}${includedir}
}
I managed to solve this problem by adding the SSTATE_DUPWHITELIST to the bitbake recipe of the package as follows:
SSTATE_DUPWHITELIST = "${TMPDIR}/PATH/TO/THE/FILES"
I added the absolute path of all of the 6,7 files that had the conflict to the list. I did that because they were basically coming from a same source and it was all safe to do that. correct me if there is a better way though.
Hope this helps someone!
I have installed two versions of opencv in my ubuntu12.04 machine , one in /usr/local/ (opencv3.0.0) and another in /usr/ (opencv2.4.9).
To activate particular version i am using these commands in terminals.
Example :To activate opencv2.4.9,
sudo sh -c 'echo "/usr/" > /etc/ld.so.conf.d/opencv.conf' (shell script)
sudo ldconfig
export PKG_CONFIG_PATH=/usr/lib/pkgconfig
After executing these commands version is changing.
Checked with command, pkg-config --modversion opencv.
Then i compiled my code and checked used libraries, Using ldd command,
It is listing opencv3.0.0 version not opencv2.4.9.
Please help correct way of switching opencv versions.
Thanks in advance
Thank you,
I found a solution for this problem, but I am not sure the solution what iIfound is correct way or not. But it is working fine for me.
When we install two versions of opencv in different locations,we will found two opencv.pc file in {path}/lib/pkgconfig/opencv.pc.
In above example opencv2.4.9's opencv.pc file is in this path usr/lib/pkgconfig/opencv.pc.
and opencv3.0.0's opencv.pc file is in this path /usr/local/lib/pkgconfig/opencv.pc
When we compile a code it will search in both location for opencv.pc configuration file, it will use which ever first it is getting, neglecting second one.
so if want compile code with particular version we need to remove this opencv.pc file from that location.
If you want to use opencv2.4.9 remove(or rename)opencv.pc from opencv3.0.0's lib/pkgconfig/ location. Again if want activate opencv3.0.0 add opencv.pc to its lib/pkgconfig/ location and remove opencv2.4.9's opencv.pc file from /lib/pkgconfig/opencv.pc.
If somebody knows a better way to do this, please comment.
You still can install both versions and append on the environment path the path of the version you want to use.
If you don't know how to change system path check this ( How to permanently set $PATH on Linux? )
I'm creating a simple RPM installer, I just have to copy files to a directory structure I create in the %install process.
The %install process is fine, I create the following folder /opt/company/application/ with the command mkdir -p %{buildroot}/opt/company/%{name} and then I proceed to copy the files and subdirectories from my package. I've tried to install it and it works.
The doubt I have comes when uninstalling. I want to remove the folder /opt/company/application/ and I thought you're supposed to use %{buildroot} anywhere when referencing the install location. Because my understanding is the user might have a different structure and you can't assume that rmdir /opt/company/%{name}/ will work. Using that command in the %postun section deletes succesfully the directories whereas using rmdir ${buildroot}/opt/company/%{name} doesn't delete the folders.
My question is, shouldn't you be using ${buildroot} in the %postun in order to get the proper install location? If that's not the case, why?
Don't worry about it. If you claim the directory as your own in the %files section, RPM will handle it for you.
FYI, %{buildroot} probably won't exist on the target machine.
I need to build the log4cxx library on a SuSE linux system where I am not root. The package manager, zypper, apparently does not know about log4cxx.
I download log4cxx and try to build with autotools
./configure
checking for APR... no
configure: error: APR could not be located. Please use the --with-apr option.
I then search for libapr:
find / -name libapr*
/usr/share/doc/packages/libapr-util1
/usr/share/doc/packages/libapr1
/usr/lib64/libaprutil-1.so.0.3.12
/usr/lib64/libapr-1.so.0.4.5
/usr/lib64/libaprutil-1.so.0
/usr/lib64/libapr-1.so.0
So I try
./configure --with-apr=/usr/lib64/libapr-1.so.0
configure: error: the --with-apr parameter is incorrect. It must specify an install prefix, a build directory, or an apr-config file.
The same for --with-apr=/usr/lib64/libapr-1.so.0.4.5 and --with-apr=/usr/lib64/.
Which file does ./configure look for? What does --with-apr expect? Is one of the two *.so.* files the needed library?
You'll probably want to install libapr1-devel so that you can compile against it. Then try re-running ./configure.
I ran into the same issue, I think you're using the source code off of appache's site which I beleive is outdated. This issue has been fixed in the SVN trunk several years ago (lolol, I guess right around the time this question was asked).
Just pull the svn trunk's source and compile it:
svn checkout http://svn.apache.org/repos/asf/incubator/log4cxx/trunk apache-log4cxx
./autogen.sh
./configure
make
make check
sudo make install
On software.opensuse.org someone has packages built for recent versions of openSUSE as well as SLE at liblog4cxx10. Maybe that'll work for you instead of building your own.
MichaelGoren is right.
There is multiple ".h" file missing.
So you have to add them before launching make.
sed -i '1i#include <string.h>\n' src/main/cpp/inputstreamreader.cpp
sed -i '1i#include <string.h>\n' src/main/cpp/socketoutputstream.cpp
sed -i '1i#include <string.h>\n' src/examples/cpp/console.cpp
sed -i '1i#include <stdio.h>\n' src/examples/cpp/console.cpp
I bumped into the same problem on 3.3.4-5.fc17.x86_64 and resolved it by including the appropriate H files to the CPP files reported by the make utility.
In my case I should run the make utility 3 times each time getting a new error and fixing it by adding the appropriate include H to the reported CPP file.
The main idea is as following:
1) Check by running the man utility, where the function mentioned in the error defined.
For example, man memmove says that it is defined in the string.h header file.
2) Add the appropriate include file to the CPP file.
For example, the make utility complains that inputstreamreader.cpp does not find the memmove function. Open the inputstreamreader.cpp file and add string.h to its header files.
3) Run the make utility until the log4cxx is compiled without errors.