I see there are many version of autoconf and automake available in my ubuntu linux.
If I want create a new project from scratch, what's best choice, latest versions or older versions?
Go with the latest version. It's only developers who are rebuilding the configure system that need to use autoconf and automake (and thus need to have the newer version installed), which likely just means "you"; it won't affect users who are just building your project using your distributed configure files.
Related
I want to run an application based on Qt5 shared objects.
Although I have apt installed qt5-default, qttools5-dev and qttools5-dev-tools I get the error bellow:
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5: version `Qt_5' not found
I have also tried to change some environment variables as LD_LIBRARY_PATH and DYLD_LIBRARY_PATH, resulted in no success!
What do you suggest?
When you built your application, which version of Qt5 did you build against? You can see this in QtCreator by looking at the currently selected kit:
If you just installed QtCreator from binary, it is shipped with it's own set of Qt5 shared libraries that your application is linked against, however your OS' version of those libraries (those installed from apt-get and similar) may not match.
When you try to run the application on it's own outside QtCreator, it may try to link against the OS version of the libs which are usually much older.
There are many ways to resolve this. One way, which would be preferred if you don't care for the newest version of Qt, is simply building towards the Qt libs supploed by the OS. You can do this by creating a new kit that specifies to build against the OS' libraries following this procedure.
Another way is shipping the shared libraries that you used from QtCreator together with the application so that those will override the OS ones. Usually just chucking them into the same folder as the executable will do the trick, as they will be found before the ones under /usr/lib/whatever etc.
Yet another way is to build your own static version of Qt and link with that. This has some benefits and some drawbacks. This is an advanced topic, so I won't go into detail (you can see here). But in this case the Qt libs are built into your app and will not depend on any external Qt libs version.
I am using the cmake to build my project. However, I need to build this project on a machine that I do not have the permission to install any software on it. I thought I can use the generated makefile but it has the dependencies on CMake,and says cmake:command not found.Is there any solution that force the generated makefile do not have any cmake related command such as check the system version? Thanks
Is there any solution that force the generated makefile do not have any cmake related command such as check the system version?
No. There is no incentive for cmake to provide such an option, because the whole point of the cmake system is that the cmake program examines the build machine and uses what it finds to generate a Makefile (if you're using that generator) appropriate to the machine. The generated Makefiles are tailored to the machine, and it is not assumed that they would be suitable for any other machine, so there is no reason to suppose that one would need to use one on a machine that does not have cmake. In fact, if you look at the generated Makefiles you'll find all sorts of dependencies on cmake.
Depending on the breadth of your target machine types, you might consider the Autotools instead. Some people dislike them, and they're not a good choice if you want to support Microsoft's toolchain on Windows, but they do have the advantage that an Autotools-based build system can be used to build software on machines that do not themselves have the Autotools installed.
one easy solution is to use static libraries and the 'static' parameter in the command line.
Then you should be able to drop the executable on the target machine and run it.
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).
I've compiled a C program under Ubuntu 12.04, built a Debian package out of it, and want to install it on a server running Debian Lenny.
Last time I did that (about two months ago) it worked: I could install the package and run the binary. But now I get the following error message:
(binary's name): /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by (binary's name))
Other than upgrading my machine to Ubuntu 12.4, the only significant change we've brought to the code is a call to strdup(), for which I had to enable the _POSIX_C_SOURCE=200809L feature test macro.
Upgrading the server to the latest Debian version is not my preferred option as it is not under my direct control.
How do I fix this problem?
I think the critical bit of info here is 'upgrading my machine'. So when this worked before, you were building and packaging on something earlier than 12.04? If so, then the issue is that 12.04 now ships with a newer version of libc (apparently 2.14), and your binary now records a dependency on that version of libc. When you try to run on Lenny, which likely uses an older version of libc, the linker detects that the Lenny version does not support the 2.14 API, and fails.
I think the best way forward is probably to do your development and testing on 12.04, and then when you want to create packages for a specific Debian release, use pbuilder or similar to create debs. This will ensure that the libraries used for the packaging build match the target platform.
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.