I am new to fedora (Linux). Just installed glib packages using yum install glib*. But still not able to compile.
I used locate to find where the pkg-config file is. I opened all of these but could not find PKG_CONFIG_PATH environment variable. Any help? :)
pkg-config files are stored in /usr/lib64/pkgconfig/* or /usr/lib/pkgconfig/* (depending on whether you're on 64-bit or 32-bit).
The glib package contains glib 1.x, for glib 2.x the right package is glib2 (backwards-incompatible API changes require a new package).
Furthermore, development headers, documentation, pkg-config files, etc., are provided in a separate package, which is usually called '$packagename-devel'. This split allows you avoid installing all the development stuff if all you want to do is use the library. So, what you really want is yum install glib2-devel.
Note that, since you know the pkg-config name, you can just do yum provides '*/glib-2.0.pc' (or provide the full path and you'll only get a single result) to find the packages which provide the glib-2.0 pkg-config file. With dnf you can also just do something like dnf install '/usr/lib64/pkgconfig/glib-2.0.pc', not sure if the version of yum from F16 can do the same or not, which brings me to…
Fedora 16 is way too old. Unless you have a very good reason for using this specific version of Fedora, stop doing so. Beyond being a much less pleasant experience, Fedora 16 is old enough that it is no longer receiving security updates. If you need to use something from that era you should find something that is still supported (RHEL 6 is based of F12, RHEL 7 is based on F19, you can use CentOS if you don't want to pay for support).
Related
I am trying to build an alternative compilation suite on my debian-testing machine (sorry, real question is actually at bottom).
Technically it is a "cross-compilation" because I need to use this toolchain on another machine, but hardware is compatible (x86_64-unknown-linux-gnu) so I don't need to bother about build/host/target differencies.
On the other hand I do need to worry about prefix/sysroot because I cannot install in any standard location (to be more precise: I could install anywhere, since I have root access there, but I shouldn't); This leaves me with my $HOME, some completely non-standard place (e.g.: /usr/local/my/toolchain) or some semi-standard (e.g.: /opt) place. In any case I will need to do something to enable compilation to find includes and libs in such places and runtime linker to find needed .so.
My requirements are:
I have a running Linux that shouln't be messed with.
This system does not have a "C" compiler.
Said linux is BusyBox-based, so I will need a substantial amount of utilities to do any serious compiling there, including make, sed, awk, ..., beside the compiler proper.
I would be happy to stuff my augmented toolchain in /opt, but that is not a requirement; any place is ok as long as it's accessible by more than a single user, I would like ot avoid installing in $HOME.
I am aware of "optware", I installed it and it does work... up to a point. Unfortunately:
It's really old software
it's only 32bit (my system is Linux syno0 3.2.40 #5004 SMP Thu Nov 6 15:26:44 CST 2014 x86_64 GNU/Linux).
Some programs won't compile because provided libs have 32/64 mismatch.
Real motivation to do all this exercise is I need to install some perl modules needed for one application that will have to run there and to install them from cpan I need a native compiler (and other stuff, of course).
Similar arguments about a Ruby-on-rails application I should port there.
If at all possible I should try to use the "native" libs in /lib:/lib64:/usr/lib:/usr/lib64:/usr/lib32 ("static" .a libs are not available).
I had a limited success preparing a custom tarball from an available toolchain for my processor, relocating it to /opt, stuffing needed apps in its sysroot and compiling with: CPPFLAGS="-I/opt/include" and LDFLAGS="-L/opt/lib -Wl,-rpath -Wl,/opt/lib".
This enables me to build almost everything "LFS-style", but it's rather error-prone and 64-bit-only.
I seem to understand it should possible to automatize all this by a careful mix of --prefix, --with-sysroot, --with-native-system-header-dir, --enable-multilib and their friends.
I tried to understand exactly how they should be used and failed, for a reason or another. I didn't find any exhaustive documentation and information in GCC instalation docs are confusing me.
Can someone, please, give me a recipe to build this toolchain?
Any pointer to in-depth documentation welcome, but I suspect some tutoring will be necessary.
I assume recompilation of Binutils and GCC is mandatory, Glib is probably not needed; anything else can be recompiled "native" on target.
TiA
ZioByte
After installing your toolchain in nonstandard places you need to set environment(maybe system-wide) correctly for GCC using LIBRARY_PATH and C_INCLUDE_PATHor CPLUS_INCLUDE_PATH.
Environment Variables Affecting GCC
I see three ways to automate setting path variables for your relocatable toolchain:
on every relocation adding your GCC path to your PATH environment variable. And create alias in your busybox profile (usually /etc/profile)
alias example:
alias gcc='TOOLCHAIN_PREFIX=$(which gcc | rev | cut -d"/" -f3-10 |rev); \
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ gcc'
creating for your toolchain launcher-script that will calculate pathes, but you'll should launch it with direct path, setting it when you launch build process, or of course you can add its location to PATH environment varaible.
script example
#!/bin/sh
TOOLCHAIN_PREFIX=$(echo $0 | rev | cut -d"/" -f3-10 |rev);
LIBRARY_PATH=$TOOLCHAIN_PREFIX/lib/ \
C_INCLUDE_PATH=$TOOLCHAIN_PREFIX/include/ \
$TOOLCHAIN_PREFIX/bin/gcc-4.*
The most reliable and ergonomic way — create install/uninstall script that will unpack and set environment correctly, to relocate toolchain you will uninstall from it from one prefix and install to another. If you have dpkg on your debian-testing system, .deb package is best choice.
I can see no way to set environment fully automatically. But we can reduce it to setting just one path — path of toolchain.
HINT* For better stability you should isolate your toolchain and also install in your prefix Linux Kernel headers and Glib
I’ve just installed the Haskell Platform on my Mac running Mavericks 10.9. The cabal version included (1.16) is out of date, and prompts me to run “cabal update” and then “cabal install cabal-install". Doing so installs cabal 1.20.0.3, but it installs in ~/Library/Haskell. This is not in my executable path, so further attempts to run cabal result in executing version 1.16 from /usr/bin, which was not updated.
I guess I could get around this by changing my executable path to include ~/Library/Haskell, with higher preference than /usr/bin. But I don’t really want to do this. And I don’t want to maintain multiple out of date versions of the software in hidden locations on my system. How do I get cabal to update the executable in the right place? Running with sudo did not help.
Edit: Updated my path, but somehow it still doesn’t work:
[76 of 76] Compiling Main ( Main.hs, dist/build/cabal/cabal-tmp/Main.o )
Linking dist/build/cabal/cabal ...
Warning: No documentation was generated as this package does not contain a library. Perhaps you want to use the --executables flag.
Installing executable(s) in
/Users/lethe/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.20.0.3/bin
Installed cabal-install-1.20.0.3
Updating documentation index /Users/lethe/Library/Haskell/doc/index.html
euclid:Public lethe$ which cabal
/Users/lethe/Library/Haskell/bin/cabal
euclid:Public lethe$ cabal --version
cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library
euclid:Public lethe$ echo $PATH
/Users/lethe/Library/Haskell/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/local/git/bin:/usr/texbin
It claims it installed cabal 1.20.0.3 to ~/Library/Haskell, and since the path is updated, it claims it’s going to execute the version in ~/Library/Haskell, but it also claims the executed version is 1.16.0.2. What’s going on here?
I also tried ghc-pkg recache and cabal install cabal-install-1.20.0.3 (with version number specified), but executed version is still 1.16.0.2
There are a couple of solutions:
1) Try updating the PATH variable such that it looks in your local path first.
(Add this to your .bash_profile: export PATH=$HOME/Library/Haskell/bin:$PATH. Source the profile and then retry the whereis command to identify which binary you are using, it should use your local one)
Though this didn't work for me. I had to resort to the next step to make it work:
2) Brute force fix: Delete /usr/bin/cabal.
Hope this helps.
According to 23skiddo at GitHub, the way to get cabal to install in the system-wide directory is cabal install --global. Also if your shell is executing the wrong path to an executable you probably need to clear the cache with hash -d cabal or hash -r.
I once had an alias to a command and forgot about it. That is not picked up by "which ".
Try $(which cabal) --version. If it shows 1.20 there may be some similar problem. Use compgen -a to list your aliases.
/Users/lethe/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.20.0.3/bin also is not /Users/lethe/Library/Haskell/bin.
Also:
There is a new Haskell-Plattform release 2014.2 now. This comes with Cabal 1.18 and GHC 7.8.3.
It updates easily to Cabal 1.20 (I don't know why it does not come with 1.20 in the first place).
I already tried many different setups between using Haskell-Plattform, Homebrew ghc + haskell-plattform and also http://ghcformacosx.github.io/
Last one makes most sense to me after trying all different ways to use Haskell on OSX.
If you switch between different "distributions" make sure you really get rid of "everything" that is installed from other versions of Haskell.
I think the most important thing is to recognize that all of those installations are more or less the same. It just moves paths and preferences around.
I am a begineer trying to get code in C. I am working on a Mac and using xcode. My only past experience has been with java using eclipse and everything was pretty straight forward. I have almost no experience with terminal.
I am required to learn a bit of C for a project I will be working on and the learning of syntax is coming along okay, but I am at a point where I need to include some libraries in my c program. Specifically I am attempting to make plots with gnuplots.
I have downloaded gnuplot-4.6.3 from their repository and I do not even know how to install the files. I have been looking around and have tried using terminal to use the ./configure command when I am in the gnuplot-4.6.3 directory. But I really don't know what I am doing so I don't even know where to go next or what to do next.
Sorry if this is so trivial, I honestly just have never done this before and I cannot find a good tutorial on what to do.
Thanks for any help you can offer.
I would recommend using MacPorts for installing third-party tools and libraries. It knows the dependencies required and will install them as part of the installation.
Download it from macports.org.
Install it, and allow it to modify your ~/.profile so that /opt/local/bin is in your $PATH (any issue then just do export PATH=/opt/local/bin:$PATH from the command line).
sudo port selfupdate
sudo port install gnuplot
Now that will install the library into /opt/local/lib with the include files in /opt/local/include, so now just add that library to your Xcode project. Select the target and in the Build Phases tab open up the Link Binary With Libraries and press the + button and select Add Other. Now find /opt/local/lib/libgnuplot.a (I am assuming that's what it's called; I don't have it installed my self):
Now add /opt/local/include to your Header Search Paths so the compiler can find the gnuplot header files. Select the target and in Build Setting type in "header search" in the search box. Now double-click on the Header Search Path in the target column (or the project column to the right) and add /opt/local/include:
It's fine! You're learning then! Keep up! When I hit this kind of problem you may want to learn about the basis for linux gcc/g++ compilation and linking processes. Then you should learn Cmake and Automake, which are basically packages to configure projects before compiling building.
A typical (good) project in Unix systems build with commands
./configure
make
sudo make install
or
cmake CMakelists.txt
make all
sudo make install
That's what you need to do after downloading a source tarball online to install unix programs.
Now since you are using Mac, there are so-called package installers, one which is macports and homebrew. I personally suggest homebrew than macports here (I've tried both, although macports still outnumber homebrew with the number of repos, homebrew has the newest support, especially when upgrading to a new OS). So to install homebrew you can do
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Execute that in your terminal (see http://brew.sh/) for more information.
Then you could simply install GNUplot by
brew install gnuplot
I'd like to use setcap, part of libcap-bin, on an embedded Linux device. I use buildroot and see that it has the packages libcap and libcap-ng available, but not libcap-bin.
I googled around but cannot find the source for libcap-bin to produce the setcap binary for the ARM target board.
On Ubuntu I just install with:
sudo apt-get install libcap-bin
Where can I get the source and how can I build libcap-bin for my ARM board?
As others have explained: you can't expect a 1:1 match between the packages you're seeing in your Ubuntu/Debian distribution and the packages you're seeing in Buildroot.
Ubuntu/Debian packages take source packages (in this case libcap) and create multiple binary packages from them, in order to allow you to install only the library, or the library + development files, or the library + programs, etc. For example, look at http://packages.ubuntu.com/source/quantal/libcap2, which is the reference page for the libcap2 source package: it gives you the list of binary packages generated in Ubuntu from this source package.
On the other hand, in Buildroot, there is only the concept of source packages. One package in Buildroot == one tarball from a given software component. Therefore, there is only package/libcap. At the moment, package/libcap/libcap.mk is written to only install the library because no-one needed the setcap and getcap programs. But you can extend package/libcap/libcap.mk (and possibly package/libcap/Config.in) to enable the compilation of the programs as well. As another commenter noted, you will need to add attr as a dependency (though the commenter wrongly said that Buildroot didn't had attr: it does have it, see package/attr).
gcc 4.4.4 c89 Fedora 13
I am wondering what is better. To give you a compile of examples: apache runtime portable and log4c.
The apr version in my fedora repository is 1.3.9. The latest stable version on the apr website is 1.4.2.
Questions
Would it be better to download from the website and install, or install using yum?
When you install from yum sometimes it can put things in many directories. When installing from the tarball you can put the includes and libraries where you want.
The log4c the versions are the same, as this is an old project.
I downloaded log4c using yum. I copied all the includes and libraries to my development project directory.
i.e.
project_name/tools/log4c/inc
project_name/tools/log4c/libs
However, I noticed that I had to look for some headers in the /usr/include directory.
Many thanks for any suggestions,
If the version in your distribution's package repository is recent enough, just use that.
Advantages are automatic updates via your distribution, easy and fast installs (including the automatic fetching and installing of dependencies!) and easy removals of packages.
If you install stuff from .tar.gz by yourself, you have to play your own distribution - keep track of security issues and bugs.
Using distribution packages, you have an eye on security problems as well, but a lot work does the distributor for you (like developing patches, repackaging, testing and catching serious stuff). Of course each distributor has a policy how to deal with different classes of issues for different package repositories. But with your own .tar.gz installs you have nothing of this.
It's an age-old question I think. And it's the same on all Linux distributions.
The package is created by someone - that person has an opinion as to where stuff should go. You may not agree - but by using a package you are spared chasing down all the dependencies needed to compile and install the software.
So for full control: roll your own - but be prepared for the possible work
otherwise use the package.
My view:
Use packages until it's impossible to do so (conflicts, compile parameters needed, ..) . I'd much rather spend time getting the software to work for me, than spend time compiling.
I usually use the packages provided by my distribution, if they are of a new enough version. There is two reasons for that:
1) Someone will make sure that I get new packages if security vulnerabilities in the old ones are uncovered.
2) It saves me time.
When I set up a development project, I never create my own include/lib directories unless the project itself is the authorative source for the relevant files I put there.
I use pkg-config to provide the location of necessary libraries and include files to my compiler. pkg-config use some .pc-files as a source of information about where things are supposed to be, and these are maintained by the same people who create the packages for your distribution. Some libraries does not provide this file, but an alternative '-config'-script. I'll provide two examples:
I'm not running Fedora 13, but an example on Ubuntu 10.04 would be;
*) Install liblog4c-dev
*) The command "log4c-config --libs" returns "-L/usr/lib -llog4c" ...
*) The command "log4c-config --cflags" returns "-I/usr/include"
And for an example using pkg-config (I'll use SDL for the example):
*) Install libsdl1.2-dev
*) The command "pkg-config sdl --libs" returns "-lSDL"
*) The command "pkg-config sdl --cflags" returns "-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL"
... So even if another distribution decides to put things in different paths, there are scripts that are supposed to give you a reliable answer to where things is - so things can be built on most distributions. Autotools (automake, autoconf, and the likes) amd cmake are quite helpful to make sure that you don't have to deal with these problems.
If you want to build something that has to work with the Apache that's included with Fedora, then it's probably best to use the apr version in Fedora. That way you get automatic security updates etc. If you want to develop something new yourself, it might be useful to track upstream instead.
Also, normally the headers that your distro provides should be found by gcc & co. without you needing to copy them, so it doesn't matter where they are stored by yum/rpm.