I recently installed Debian Squeeze on my machine with C++ programming practice as one of the main goals. I use Boost libraries regularly in my projects. On OS-X and Windows, I had to manually install Boost header libraries prior to using them. However, regarding Linux, the front page of the Boost website mentions
Popular Linux and Unix distributions such as Fedora, Debian, and NetBSD include pre-built Boost packages.
I use mainly the header libraries, not pre-built packages for my current projects. So my question is: Are the header libraries installed by default anywhere on Debian or do I have to install them? I have already looked in /usr/include and it doesn't seem to have any Boost directory. I have googled as well as looked up related discussions on SO, but didn't get a clear answer to my question. If I do have to install the header libraries, is there an 'apt-get' way of doing it or I simply untar and place in a convenient location (/usr/local/include) ?
Second, if I need to manually place the boost headers (say in /usr/local/include/), should the version of the headers match with the pre-installed packages for compatibility with any potential future projects which use both the binaties (libboost-*) and header files?
I am fairly new to programming on a Linux platform. Although, I can make things work using patch-and-match (and googling), I am looking for guidance on long term best practices.
Thanks.
Saying a GNU/Linux distribution "includes" a package such as Boost doesn't mean it is installed automatically, it means the package is available for installation, using your system's package management tool. The package might be tailored for your distribution, so it integrates well with the rest of the OS, or it might just be identical to the upstream version and the benefit is just that it's already built for you and convenient to install from within the OS.
There is tons of documentation on Debian's package mgt tools:
http://wiki.debian.org/PackageManagement
http://www.debian.org/doc/manuals/debian-faq/ch-pkgtools.en.html
http://www.debian.org/doc/manuals/debian-reference/ch02.en.html
So yes, you want to apt-get (or the equivalent with another of Debian's tools) to install Boost in /usr/include, that will be much easier than manually installing them. If you later decide to install Boost manually, keep that installation entirely separate from the system packages, so the libraries and headers from the newer version don't conflict with the system packages. If it's a single-user machine and you don't need the packages to be available to other users on the machine then you can just install them in your home directory, rather than /usr/local/ (which requires superuser access, and you should do as little as possible as the root user)
Related
I develop a utility in Go that requires recent version of sqlite. I'm interested only in targeting specific architecture, to be specific: x64 linux. I'm developing that utility on Mac OS X. I'm using go-sqlite3 driver. I use GNU Make + Glide to build my utility. In order to cross compile on my Mac I pass specific arch flags to make.
Repos on Linux platforms that I'm targeting usually have quite old versions of sqlite that don't have features that I need in my utility.
I can manually compile and install required version of sqlite on all the platforms that I need, but it is quite cumbersome. I wonder if there is a good way to either statically link a specific version of sqlite or somehow bundle a utility with specific version of sqlite dynamic library.
Even though I mention sqlite a lot, this question can be generalized to other libraries: how to bundle a golang app with a specific version of C library an outdated version of which may be installed on the target platform.
Also: how to better organize development of that utility so that other devs won't need to manually compile and install specific version of the library - the preference is to use Makefile that would build all the binaries for required target platform. I see that I can just copy code of specific version of library (e.g. sqlite) to my utility's repo though I wonder if there is a better option - maybe I can somehow use glide dependencies for that purpose and build library that I need as part of my other dependencies.
The original question, Packaging Go application for Debian, was asked over three years ago, when Go was statically linking executables.
Now, with the new Go 1.5 Release, whose release note says,
Changes to the linker enable distributing Go packages as shared libraries to link into Go programs, and building Go packages into archives or shared libraries that may be linked into or loaded by C programs
I headed to Debian GoPackaging wiki, but only to find out that it has not been updated to Go 1.5 yet, maybe the wiki is not maintained, or maybe not, but,
I just want to know, if I want to package a tool that depends on nothing but the official Go packages, how should I take advantage of the shared libraries, instead of building my app into a humongous statically linked executable?
I know the official answer may take some time, but I can wait.
Thanks to Braiam's answer, I moved a bit further.
I followed the blog to the step head -100 debian/**/*, but my output is completely different from the blog's. Mine is just the following. Anyone knows why and how to fix?
$ head -100 debian/**/*
3.0 (quilt)
I tried to run gbp buildpackage --git-pbuilder but bumped into error:
gbp:info: Building with (cowbuilder) for sid
Base directory /var/cache/pbuilder/base.cow does not exist
gbp:error: 'git-pbuilder' failed: it exited with 1
I checked and verified that I already have cowbuilder & pbuilder installed:
ii cowbuilder amd64 pbuilder running on cowdancer
ii pbuilder all personal package builder for Debian packages
What's wrong? This pbuilder thing is new to me as I build Debian/Ubuntu Package with Docker.
The easiest method is to use dh-make-golang and verify/correct the autogenerated files. Otherwise you must follow Debian Packaging Guide and create debian/* directory and editing the control and rules file to match the examples.
I am going to analyze some ".so" shared libraries in Ubuntu. To do that, I have to install or re-install these libraries manually, using their corresponding packages. My question is that what is the safest way to do it? Can I build them in a way that the system's already installed libraries are not touched/damaged?
Can I build them in a way that the system's already installed libraries are not touched/damaged?
Yes: for every sane package, make builds the libraries, and only make install installs them. So don't do make install and your system libraries will not be touched.
P.S. You should not be running as root, and if you are not, then make install will fail anyway, because unprivileged users can't overwrite system libraries.
I am working on CentOS 6 machines, which has very old GCC/GlibC version. I want to build the whole glibc, binutils, gcc toolchain with latest or at least very recent versions in order to use c++11 support in latest gcc, and ld.gold in recent binutils, and possibly improvements in recent glibc.
I want to put the whole toolchain in some separate directory, and not to influence any existing system files. I also want to build gcc with --sys-root so that when using the gcc, I don't need to specify -I/some/directory/include and -L/some/directory/lib or whatever other parameters. Also the generated executable will automatically use the new ld-linux-xxxxx program loader which will automatically find the new libc.so.
Anyone knows if there exists some tutorial on this task?
The compiler is very dependent on glibc, altough you manage to build the compiler either in a chrooted system or equivalent, you will need to build also all libraries needed with the program you will build with this new compiler.
The best you can do is use a fresh new system (vm or whatever) or upgrade your existing one
You can download the latest toolchain from Openembedded or Yocto.
And here you don't have to do any package installation to your current system.
Just download the toolchain, source the environment and thats it you are ready to check the c++11 support.
The location to download the toolchain:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/toolchain/ (Just select the architecture either 32bit or 64 bit based on your machine support)
If you need the latest toolchain, you'd better migrate to Fedora.
If you can't/won't, the best bet is to get the pieces as source RPMs for CentOS and Fedora, unpack them and fix up the CentOS by pilfering the sources and patches from Fedora, take care it doesn't overrule the system packages, correct versions and fix to install elsewhere (don't mess up your system too much! /usr/local comes to mind). The pieces are at least binutils, gcc.
I do not knwo Why you need this ? If this is needed that to compile for another computer, I would suggest using a virtual machine running the same OS as target. much more easier !!
I love coding in Haskell, but often am on a computer where I cannot install software, and which has some restrictions about what you can run. I would like to write Haskell code and test it while on this computer. Does anyone know of version of Haskell, interpreted or compiled, written in Java, JavaScript, Ruby, Python, or another interpreted language available in the default install on a Mac? A standalone version of Haskell which can be installed at the user level works too, but compiling Haskell myself is not an option.
The GHC binary distributions (the ones that come as tarballs, not installers) all can be installed locally trivially easily.
./configure --prefix=$HOME/ghc
make install
Then update your path to include $HOME/ghc/bin
If you want cabal, get the tarball from hackage, then untar it and run bootstrap.sh.
GHC works really well as a local install. In fact, I never use it as a system install.
I do this on my workstation, too, so that the distribution I'm on (Debian in my case) doesn't suddenly start upgrading stuff without me noticing in a simple apt-get upgrade.
This solution installs a full ghc and haskell-platform as well as ~/.cabal prefix.
First of all, I have a ~/local directory that I use in order to put custom-compiled programs in my home directory. I usually dislike the sudo make install step, because I'm giving some random Makefile root access to my system, and that makes me feel queasy.
Then I download the ghc binary distribution from the ghc site. NOTE that I linked you to 7.4.2. I hear there's some segfault bug on Mac OS X, but I'm not aware of the details. You should check that out or get the newer ghc instead, but be aware that there are many packages on hackage that are not yet fixed to work with 7.6. Also, ignore that "STOP!" warning, you're the 1% who actually want a non-distrib GHC binary.
You can just cd into the ghc directory, then do ./configure --prefix=$HOME/local/haskell or so, followed by make install (no compiling necessary, it's just going to install, not compile.)
At this point, you should add ~/local/haskell/bin to your path. Here's the code that I put in my ~/.zshrc, which will add all ~/local/*/bin directories to your path.
You can then get the Haskell Platform, and do the same ./configure --prefix=$HOME/local/haskell && make && make install dance. This step will need compilation. It means that you will need some header libraries installed. I find the random openGL headers that are necessary particularly annoying.
You can also of course skip haskell-platform, and just download cabal-install directly, then install what you need. You should in any case not forget to add ~/.cabal/bin to your $PATH!
Do a cabal update and you should be good to go.
NOTE: there's one important part that the binary distribution of GHC needs, which can sometimes be a pita on old Linux systems: libgmp. It's linked dynamically against it, and if you get some errors about the shared libgmp not being found on OS X, too, you can… well, ask that question in a comment, and I shall explain how to get there. Basically, you'll have to compile libgmp + deps yourself.
But I don't think that should be a problem on OS X. It's just been a problem on a couple old debian boxes I've tried this on.
For single files, you can use codepad.