Arch Linux

(Simo: excuse me for accidently assigning this to you, some weird combo on my laptop keyboard in the dark did that...)

Sounds strange but just run kde-config instead of /opt/bin/kde-config.

It's not me. It's 'configure' script of every single KDE3-related package.

This might be a problem of fakeroot and not kde-config. I am sure this worked well in the past. Maybe updating to latest (or downgrading to previous) fakeroot or even switching to fakeroot-ng might help.

@Andy: Do you have any ideas? kde-config works fine when called without the absolute path and it also works fine as root.

please contact the Debian upstream maintainer for fakeroot. I have no qt(3/4) here installed. I can't confirm this and will not spend much time for further investigation into this. Sry. Other projects keep me busy these days.

If you have a solution drop me a comment here or via IM / mail.

I don't have any problem running /opt/kde/bin/kde-config from fakeroot on my i686 system.

I have x86_64.

I can confirm this on x86_64. i686 works fine indeed -> added myself to the assignees just in case I come by a solution

I can confirm this on x86_64. i686 works fine indeed -> added myself to the assignees just in case I come by a solution

I can confirm this on i686 with fakeroot v1.11.4-1

I can't find an upstream report. Please one of the affected people file an upstream issue and give us the url to follow.

How's the new pkg from testing working?

same segfault. I'll see if I can file a bug upstream.

any idea if they have a bug tracker or a devel mailing list, I can't seem to find a proper place to report it? I only found a commit mailing list but that is of no use here.

https://bugs.kde.org/query.cgi - there's a section for kdevelop

Its a bug in fakeroot not kdevelop.

It is http://bugs.debian.org/cgi-bin/pkgreport.cgi?package=fakeroot
I tried to recompile kdelibs3 with --enable-debug to include meaningful backtrace from the crash,
but kdelibs3 refuse to build (with enable and with disable debug options)...

Pulling in some people - makepkg and fakeroot issue. Thomas was the last person to fix a fakeroot bug, so maybe he knows something

Okay, this is weird but does not only affect kde-config, it seems mplayer and kde4 also have the same problem. My guess is that it is a problem of fakeroot, glibc and x86_64. I also tested fakeroot-ng a while back and it is completely unusable.

I have no idea where to start here, but makepkg-git solves these problems as it only runs inside fakeroot during package() (not during build()), eliminating these problems altogether (the cp, mv, install, mkdir tools still work fine inside fakeroot).

I have similar problem while building amarok2-svn from AUR. During the compilation something (haven't discovered what exactly yet) segfaults, but when building as root everything is fine.

I think we can solve some of these problems with the makepkg build()/package() split that will soon be coming. It comes down to fakeroot not handling a situation correctly, which unfortunately we can't do much about unless someone wants to really go digging into the fakeroot code and fix things the upstream developers can't even solve.

The problems is with the GL library from nvidia drivers. The trivial example to reproduce this is:

#include <stdio.h>

int main(int argc, char *argv[])
{
printf("Hola Arch Linux\n");

return 0;
}

compile with gcc hola. -o hola -lGL

then:

LD_LIBRARY_PATH=/usr/lib/libfakeroot LD_PRELOAD=libfakeroot.so LD_DEBUG=files ./hola #fail when run with libGL (that load libnvidia-tls) but not with the libGL package from ArchLinux mesa3D.

can see,
19174: ./hola: error: symbol lookup error: undefined symbol: pthread_key_create (fatal)

then rebuild hola with gcc hola. -o hola -lGL -lpthread, this undefined symbol disapear, but always crash :(

There are importan notes on README.txt from nvidia, that can be useful, about TLS and pthreads and dlopen(), also i tried to link "faked" and "libfakeroot" to -lpthread but, not solves the problem.

Oh, maybe this is related... README of fakeroot:

fakeroot can be built to either use SYSV IPC or TCP for message passing.

Cases for which the SYSV IPC version fails or causes problems but for
which fakeroot-tcp has been observed to work well include the items
listed below.

* Multithreaded applications (using pthread)
* Running under realtime-preempt kernel

Thanks for pointing this out. For archlinux developers (and TUs?) this shouldn't be a problem, as we have to build in a chrooted environment anyways. Installing nvidia or AMD libGL instead of mesa libGL inside the clean build chroot is not the right thing to do.

Is this ONLY the nvidia libGL? If so, we could simply all build in a chroot with only mesa's libGL installed.

I just closed  bug 12766 , which is about mplayer compilation that breaks with the latest nvidia drivers. Building in chroots is a solution, but what about users who want to build mplayer with nvidia vdpau? They can't use fakeroot to build the package.

iuupiii! :)

Hi i again here. I tested to build fakeroot --with-ipc=tcp and then the problem dissapear :) can run the binary linked to libGL -> libnvidia-tls inside this :)

[djgera@gerardo ~]$ gcc hola.c -o hola -lGL
[djgera@gerardo ~]$ ldd hola | grep tls
libnvidia-tls.so.1 => /usr/lib/tls/libnvidia-tls.so.1 (0xb6ea9000)
[djgera@gerardo ~]$ fakeroot ./hola
Hola Arch Linux

There are two solutions for common users that have nvidia and don't use the chroot for build:

* Using fakeroot compiled "--with-ipc=tcp" maybe the fakeroot package can install both fakeroot (the current with sysv ipc, and fakeroot-tcp) and a flag for makepkg select the desired fakeroot.

* Using a "dirty hack" using the libGL.so.1.2 from libgl package for example:

[djgera@gerardo ~]$ fakeroot ./hola
/usr/bin/fakeroot: line 178: 2492 Segmentation fault FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH="$PATHS" LD_PRELOAD="$LIB" "$@"
[djgera@gerardo ~]$ ls -l libGL.so*
lrwxrwxrwx 1 djgera djgera 10 2009-02-18 15:44 libGL.so -> libGL.so.1*
lrwxrwxrwx 1 djgera djgera 12 2009-02-18 15:44 libGL.so.1 -> libGL.so.1.2*
-rwxr-xr-x 1 djgera djgera 525761 2008-09-25 14:56 libGL.so.1.2*
[djgera@gerardo ~]$ LD_LIBRARY_PATH=. fakeroot ./hola
Hola Arch Linux
[djgera@gerardo ~]$ LD_PRELOAD=./libGL.so.1.2 fakeroot ./hola
Hola Arch Linux
[djgera@gerardo ~]$

I contacted the author of the fakeroot and told me to create a ticket in bugtraker Debian, put the link here for further information.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516024

New version, 1.12.2, but the bug is still there. Any news?
The bug report in debian seems to be stuck as well...

I have this problem when trying to compile mplayer. I've read that you can use the parameter --asroot when you run makepkg but I really don't like the idea of doing that so until this is fixed I came up with a few extra steps to get around it. I didn't see anybody mention this workaround already so I thought I'd post it if people still aren't able to compile something they need.

Edit /etc/makepkg.conf so that you disable fakeroot. (Just add ! in front of fakeroot)
e.g. BUILDENV=(!fakeroot !distcc color !ccache !xdelta)

Now you can build the package using makepkg without segfaults from fakeroot. The only problem now is that ownership will be set incorrectly on the files in the package itself. To fix that just extract the package to an empty directory, change the ownership inside and repackage it. This is how it's basically done:

mkdir temp
tar -C temp -xvf package.tar.gz
rm -f package.tar.gz
sudo chown -R 0:0 temp
cd temp
tar -cvzf ../package.tar.gz .PKGINFO *
cd ..
rm -rf temp

Of course if your package includes .INSTALL just add that after .PKGINFO when you package it.
And then don't forget to reenable fakeroot in your /etc/makepkg.conf so that your other builds don't get messed up with incorrect ownership.
Since the fakeroot problem seems to really only affect a small amount of packages, this isn't to much to go through for one when you need to build it. I've only experienced the problem when building mplayer myself.

@ben: Just preload the libGL from libgl package as i commented above ;)