Sorry I know this is stupid but where is linux libc source code available? What I downloaded from GNU didn't seem to be what I wanted, specifically I could find nothing in the pthreads function family.
Is there an online (hypertexted cross-referenced) version somewhere?
Most linuxes use a libc version named glibc.
The LXR (online cross-reference system) for glibc is e.g. here http://koala.cs.pub.ro/lxr/glibc/ for 2.9 version (link is broken). I must say that something may be not lxr'ed because some sources are generated in the build process, for example - as i can remember - wrappers around a system calls.
Pthreads are in nptl/ folder. Right link to libc sources is http://ftp.gnu.org/gnu/glibc/glibc-2.14.tar.bz2 (or change 2.14 to your version)
Update: After closing of koala's lxr, there are:
Metager with glibc: http://code.metager.de/source/xref/gnu/glibc/ (Served with Sun's OpenGrok, which was originally used to generate online x-ref for Solaris/OpenSolaris)
Google code search (I know that it was closed; but I also know it's other version which is up): http://code.google.com/codesearch and try to search something glibc-specific
UPD (march 2013) They killed codesearch again:
404. That’s an error.
The requested URL /codesearch was not found on this server. That’s all we know.
UPD 2017
Metager with glibc: http://code.metager.de/source/xref/gnu/glibc/
There is online git by glibc authors: https://sourceware.org/git/?p=glibc.git (tree is browserable at https://sourceware.org/git/?p=glibc.git;a=tree)
Glibc git is mirrored to github (which has some searching functions) https://github.com/bminor/glibc Buildroot 2018.05 notably uses this mirror.
There is search like google's codesearch in all debian packages: https://codesearch.debian.net/. It can search in glibc sources by "package:glibc request" request and also have file browser: http://sources.debian.net/src/glibc/
Info on the glibc repository: http://sourceware.org/glibc/wiki/GlibcGit
Clone it to get your own copy and search it however you like:
git clone git://sourceware.org/git/glibc.git
I load it up in an IDE project (using whatever preferred IDE) and the code navigation works quite well to let me find what I'm interested in.
Browse the source online http://sourceware.org/git/?p=glibc.git
If you're on a Debian-derived system, you can use apt-get source libc6. This will unpack a eglibc-2.12.1 directory (version number might differ, of course) in your current working directory, and the pthreads support are in the nptl/ directory below that. linuxthreads/ is for the older threading style, in case you're an archaeologist.
Try the FreeBSD and Linux Kernel Cross-Reference.
Have fun :)
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 currently running SBCL with quicklisp. I found an old project that I was trying to load with
(ql:quickload "project")
when I get the dependency error SYSTEM FILE-IO NOT FOUND. The dependencies in my project.asd file are
:depends-on (#:file-io #:cl-ppcre #:logv #:cl-mustache #:local-time
#:rutils #:alexandria)
None of the other dependencies give me any trouble, logv seems to be a discontinued log viewer, but I can't find anything concerning "file-io" in https://www.quicklisp.org/beta/releases.html. Is it just another discontinued library? Any ideas/advice would be appreciated.
The code provided by file-io only deals with slurping and spitting files. You can safely download the system from github and install it in Quicklisp's "local-projects" directory. Alternatively, you can use UIOP equivalent functions, which are well supported and available in most distributions.
I need the library Cyrus SASL as a static library on Windows (https://cyrusimap.org/mediawiki/index.php/Downloads#SASL_Library)
How to do that ?
As far as I know, you will need a MinGW and MSYS environment and then just build the SASL from sources like it were on Unix-like, i. e.
./configure
make
make install
You will get some *.a files -- those are static libraries, built with MinGW, they should work for Windows.
I'm still checking this topic, so I'll add some more info if I'm done with it.
For more reference about building projects from sources check the INSTALL file in your project's root directory, i. e. cyrus-sasl-<version>/INSTALL
upd: this seems to be not an easy thing to do, check out this article
upd2: if you prefer Visual Studio, you could check this rather outdated howto.
upd3: in general good article from GNU
These are not installed on Android 4.2.1 by default, so is it possible to cross-compile the source for e.g. GNU grep or find and have it run on Android? ( Preferably without having to root the device or installing some app off PLAY e.g. busybox.) Are there any missing dependencies that will prevent this? I am developing on Ubuntu 10.0.04
Strange. I have them on /system/xbin/*. Maybe more luck with busybox. busybox find busybox grep Not sure if busybox is installed by default on Android 4.2 tho, but it's a pretty common binary.
This is not a complete answer because I haven't tried building grep or find. However, in general it is quite possible to build GNU utilities for Android. To do this, the best option is:
Download the Android native development kit
Build an Android standalone toolchain by referring to docs/STANDALONE-TOOLCHAIN.html in the NDK
Simply build the relevant GNU utility using the normal ./configure && make mechanism.
You'll then need to copy the resulting binaries onto your Android device, which you can do using adb push. You may need to arrange to put them into /data/ somewhere because /mnt/sdcard is often marked non-executable.
Missing dependencies
The main problem you'll find during the actual builds is that Android does not use the standard GNU libc (glibc). Instead, it uses its own, called Bionic. This does miss certain important APIs - for example, wide character string support.
I've found for some GNU utilities this is OK and they can be compiled with minimal source code changes.
However, if you run into trouble, you're probably better off using other versions of these utilities which are typically designed for more flexibility in terms of the underlying libc. Specifically, the previous advice about using busybox is excellent. If you don't wish to install it from the Android market, you can find the source code here.
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.