KDE CVS/Subversion Split Ebuilds (Replies Part 1)

Message

mirage032 · Post by **mirage032** » Mon Dec 12, 2005 12:05 am

I get an error with kdelibs-7-r2 :\
I have autoconf 2.59 installed but I get :

 * Updating working copy of kde/branches/KDE/3.5/kdelibs recursively
   SVN: At revision 487791.
 * Copying files over ...
 * Moving branches/KDE/3.5/kde-common/admin to /var/tmp/portage/kdelibs-7-r2/work/branches/KDE/3.5/kdelibs
 * Bootstrapping with elibtoolize
 * Running elibtoolize in: branches/KDE/3.5/kdelibs/admin
 *   Applying portage-1.4.1.patch ...
 *   Applying max_cmd_len-1.5.0.patch ...
 *   Applying sed-1.4.3.patch ...
 * Applying kdelibs-7-knotify-noarts.patch ...                            [ ok ]
>>> Source unpacked.
QA Notice: USE Flag 'kernel_linux' not in IUSE for kde-base/kdelibs-7-r2
This Makefile is only for the SVN repository

./admin/cvs.sh: line 33: --version: command not found
*** AUTOCONF NOT FOUND!.
*** KDE requires autoconf 2.53 or newer
make[1]: *** [cvs] Erreur 1
make: *** [all] Erreur 2

!!! ERROR: kde-base/kdelibs-7-r2 failed.
!!! Function kde_src_compile, Line 138, Exitcode 1
!!! no configure script found, generation unsuccessful
!!! If you need support, post the topmost build error, NOT this status message.

mirage032 · Post by **mirage032** » Mon Dec 12, 2005 11:07 pm

I just found out what the problem is :
I had to do:

Code: Select all

make -f admin/Makefile.common

but if anyone knows how to add it manually in the ebuild or have a patched ebuild,
don't hesitate to paste a link or what to do to get it.
btw, do you know where to find kdelibs-7-r3 ? I have only the r2 version in my portage.
Thanks in advance

Bonkie · Post by **Bonkie** » Mon Dec 12, 2005 11:23 pm

mirage032 wrote:I just found out what the problem is :
I had to do:
Code: Select all
make -f admin/Makefile.common
but if anyone knows how to add it manually in the ebuild or have a patched ebuild,
don't hesitate to paste a link or what to do to get it.
btw, do you know where to find kdelibs-7-r3 ? I have only the r2 version in my portage.
Thanks in advance

There is no kdelibs-7-r3

Ill look into the problem this weekend (or sooner if I find the time). It should be executed by the ebuild :S

Merlin-TC · Post by **Merlin-TC** » Tue Dec 13, 2005 6:35 am

Didn't we make unsermake the default some time ago?

Bonkie · Post by **Bonkie** » Tue Dec 13, 2005 10:37 am

Yes, but that doesn't mean we dropped automake support.

But on my system kdelibs compiles fine with automake, guess there's something wrong on your system. Send me your emerge info if you can.

mirage032 · Post by **mirage032** » Tue Dec 13, 2005 11:18 am

Here is my emerge --info

Code: Select all

Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r3, 2.6.14-gentoo-r2 x86_64)
=================================================================
System uname: 2.6.14-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3200+
Gentoo Base System version 1.12.0_pre11
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.59-r7
sys-devel/automake:  1.4_p6, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1-r1
sys-devel/libtool:   1.5.20-r1
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig distlocks keepobj sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo"
LANG="fr_FR@euro"
LC_ALL="fr_FR@euro"
LDFLAGS="-Wl,-z,now"
LINGUAS="fr"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/overlays/bmg-main /usr/local/overlays/kde-live"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X alsa amd64 apache2 athlon64 audiofile avi bash-completion berkdb bitmap-fonts bzip2 cdr crypt cups dba dvd dvdr eds emboss en encode expat fam ffmpeg foomaticdb fortran fr ftp fuse gd-external gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 idn imagemagick imlib intel8x0 ipv6 java jpeg kde lcms libwww lzw lzw-tiff mad matroska mhash mng motif mozilla mp3 mpeg ncurses nls opengl pam pascal pcre pdflib perl php png postgres python qt quicktime readline sdl spell ssl tcltk tcpd threads truetype truetype-fonts type1-fonts udev unicode unsermake usb userlocales vlc xml2 xv zlib linguas_fr userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET

superstoned · Post by **superstoned** » Tue Dec 13, 2005 6:13 pm

what can i do about this?

configure: WARNING: Your libstdc++ doesn't appear to be patched for
visibility support. Disabling -fvisibility=hidden
checking whether x86_64-pc-linux-gnu-g++ supports -fvisibility=hidden... yes
checking if Qt is patched for -fvisibility... no

(i run a pre-4 gcc)

superstoned · Post by **superstoned** » Tue Dec 13, 2005 6:55 pm

and now i'm busy checking configure, kopete tells me i dont have libssl, libibn, libxml2 and some other libs. which i DO have. ???

even more weird, he tells me kopete doesn't have these libs while configuring and building kde-base/dcoprss-7... WTF?!?!?

is this on my side, or due to problems in the ebuilds?

Bonkie · Post by **Bonkie** » Tue Dec 13, 2005 9:09 pm

superstoned wrote:what can i do about this?

configure: WARNING: Your libstdc++ doesn't appear to be patched for
visibility support. Disabling -fvisibility=hidden
checking whether x86_64-pc-linux-gnu-g++ supports -fvisibility=hidden... yes
checking if Qt is patched for -fvisibility... no

(i run a pre-4 gcc)

You can run gcc4, AFAIK the path is only for gcc4 visibility support.

superstoned · Post by **superstoned** » Tue Dec 13, 2005 9:28 pm

Bonkie wrote:
superstoned wrote:what can i do about this?

configure: WARNING: Your libstdc++ doesn't appear to be patched for
visibility support. Disabling -fvisibility=hidden
checking whether x86_64-pc-linux-gnu-g++ supports -fvisibility=hidden... yes
checking if Qt is patched for -fvisibility... no

(i run a pre-4 gcc)
You can run gcc4, AFAIK the path is only for gcc4 visibility support.

hmmm. i have some memory of limited -fvisability=hidden support for gcc 3.4.x?!? well, i hope gcc4 will be kind'a stable soon, i'll try it as soon as it gets unmasked. i've fiddeled enough with glibc and other stuff, so i rather have at least SOME things stable

Bonkie · Post by **Bonkie** » Tue Dec 13, 2005 10:05 pm

yes there is visibility support in gcc-3.4.x but its not default afaik.

And its not the code in the ebuild that is disabling visibility so nothing I can do about I think.

Bonkie · Post by **Bonkie** » Tue Dec 13, 2005 10:12 pm

superstoned wrote:and now i'm busy checking configure, kopete tells me i dont have libssl, libibn, libxml2 and some other libs. which i DO have. ???

even more weird, he tells me kopete doesn't have these libs while configuring and building kde-base/dcoprss-7... WTF?!?!?

is this on my side, or due to problems in the ebuilds?

If it happens during configure for dcoprss I shouldn't worry about it, that's a small side-effect with the split ebuilds. Kopete and dcoprss are both in kdenetwork, so they share the same configure checks (although they should only share the ones they have in common) so when you emerge dcoprss, kdenetwork's configure goes looking for those libraries for kopete, but since we are not compiling kopete ... As long as kopete finds those libraries -when emerging kopete- everything is fine

superstoned · Post by **superstoned** » Wed Dec 14, 2005 9:05 am

Bonkie wrote:
superstoned wrote:and now i'm busy checking configure, kopete tells me i dont have libssl, libibn, libxml2 and some other libs. which i DO have. ???

even more weird, he tells me kopete doesn't have these libs while configuring and building kde-base/dcoprss-7... WTF?!?!?

is this on my side, or due to problems in the ebuilds?
If it happens during configure for dcoprss I shouldn't worry about it, that's a small side-effect with the split ebuilds. Kopete and dcoprss are both in kdenetwork, so they share the same configure checks (although they should only share the ones they have in common) so when you emerge dcoprss, kdenetwork's configure goes looking for those libraries for kopete, but since we are not compiling kopete ... As long as kopete finds those libraries -when emerging kopete- everything is fine

well, kopete works fine, so i guess its all-right. and i'm looking for visibility support in gcc 3.4, but maybe i should keep it for 4, so i have something to be amazed about (its supposed to be quite a bit faster, after all).

Bonkie · Post by **Bonkie** » Wed Dec 14, 2005 9:58 am

superstoned wrote:i'm looking for visibility support in gcc 3.4, but maybe i should keep it for 4, so i have something to be amazed about (its supposed to be quite a bit faster, after all).

If you're sure your gcc is patched with visbility support (this isn't always the case, it was original gcc 4.x code), then you can turn off the check on Qt, by changing the qt ebuild:

Code: Select all

   # patch for qt symbol visibilty support, if >=gcc-4.0.0
    # see http://bugs.kde.org/show_bug.cgi?id=109386
    if use symbol_visibility; then
        if [[ "$(gcc-major-version)" == "4" ]]; then
            epatch "${FILESDIR}/${P}-visibility.patch"
            einfo "Symbol visibility support: auto"
            USE_SYBMBOL_VISIBILITY="yes"
        else
            einfo "Symbol visibility support: disabled"
            ewarn "You need >=sys-devel/gcc-4.0.2-r1 for symbol visibility"
            ewarn "Then recompile qt AND kdelibs with the rest of KDE"
            ewarn "Dont try if you dont know what you're doing"
        fi
    else
        einfo "Symbol visibility support: disabled"
    fi

... to ...

Code: Select all

   # patch for qt symbol visibilty support, if >=gcc-4.0.0
    # see http://bugs.kde.org/show_bug.cgi?id=109386
    if use symbol_visibility; then
            epatch "${FILESDIR}/${P}-visibility.patch"
            einfo "Symbol visibility support: auto"
            USE_SYBMBOL_VISIBILITY="yes"
    else
        einfo "Symbol visibility support: disabled"
    fi

Make sure you recompile the whole of KDE after you recompile Qt. If it works for you, ill disable the gcc check in the Qt ebuild

Merlin-TC · Post by **Merlin-TC** » Wed Dec 14, 2005 10:30 am

Afaik was the visibility support in gcc 3.4 really buggy as it was patched in only in Gentoo.

I tried it before and it caused lots of problems for me especially with kmail.

superstoned · Post by **superstoned** » Wed Dec 14, 2005 1:26 pm

Merlin-TC wrote:Afaik was the visibility support in gcc 3.4 really buggy as it was patched in only in Gentoo.

I tried it before and it caused lots of problems for me especially with kmail.

i won't use it then. i just almost finnished recompling my whole system because of some glibc patches i added, and the KDE 3.5 startup patches, so i have had it with recompiling everything (didn't go very smooth). but, thanx, bonkie, for the help and comments!

i just wait for GCC 4.1 to be stable

mirage032 · Post by **mirage032** » Thu Dec 15, 2005 10:37 pm

Code: Select all

./admin/cvs.sh: line 33: --version: command not found
*** AUTOCONF NOT FOUND!.
*** KDE requires autoconf 2.53 or newer
make[1]: *** [cvs] Erreur 1
make: *** [all] Erreur 2

I noticed that the error was produced by doing :

Code: Select all

echo `$AUTOCONF --version | head -n 1`
bash: --version: command not found

AUTOCONF wasn't set... ( maybe it just didn t like emerge -P ),
the same goes for AUTOMAKE and AUTOHEADER.
So I typed:

Code: Select all

export AUTOCONF=autoconf 
export AUTOMAKE=automake
export AUTOHEADER=autoheader

Bonkie · Post by **Bonkie** » Thu Dec 15, 2005 11:53 pm

mirage032 wrote:export AUTOCONF=autoconf
export AUTOMAKE=automake
export AUTOHEADER=autoheader

Looks like something is broken in your system, those are vars set by portage iirc, im gonna guess regular kde ebuilds will generate the same error.

Bonkie · Post by **Bonkie** » Sun Dec 18, 2005 5:27 pm

For those who are running ~x86 and/or have upgraded findutils to 2.4.0 and were experiencing problems with various ebuilds, I have uploaded a fix to playground, and to playground only because I fear the fix might not solve all breakages ...

The fix solves errors like "No Makefile present in <directory>", because some directories were not copied over to /var/tmp/portage. That should not occur anymore

ktech · Post by **ktech** » Mon Dec 19, 2005 10:02 am

Bonkie wrote:For those who are running ~x86 and/or have upgraded findutils to 2.4.0 and were experiencing problems with various ebuilds, I have uploaded a fix to playground, and to playground only because I fear the fix might not solve all breakages ...

The fix solves errors like "No Makefile present in <directory>", because some directories were not copied over to /var/tmp/portage. That should not occur anymore

you're the man.

thanks!!

Bonkie · Post by **Bonkie** » Tue Dec 20, 2005 2:32 pm

Added ebuild to playground for kopete making use of the kopete's new separate branch. Its not part of KDE 3.5, nor any other KDE (planned) release, but the devs dont feel like waiting for KDE4 ... Test away.

ktech · Post by **ktech** » Wed Dec 21, 2005 6:44 pm

hey, thanks for that kopete ebuild. Newer kopete is nicer than stable one.

I was going to tell you that you should add the fetch and compile of skype plugin for kopete, but it doesn't compile with newer dbus, so we should wait until newer skype is released that supports newer dbus.

superstoned · Post by **superstoned** » Wed Dec 21, 2005 7:03 pm

ktech wrote:hey, thanks for that kopete ebuild. Newer kopete is nicer than stable one.

I was going to tell you that you should add the fetch and compile of skype plugin for kopete, but it doesn't compile with newer dbus, so we should wait until newer skype is released that supports newer dbus.

i'd like to add my thanx here, too - kopete from trunk is cool. but won't we run into trouble when it gets ported to Qt >4.x?

ktech · Post by **ktech** » Wed Dec 21, 2005 7:19 pm

superstoned wrote:
ktech wrote:hey, thanks for that kopete ebuild. Newer kopete is nicer than stable one.

I was going to tell you that you should add the fetch and compile of skype plugin for kopete, but it doesn't compile with newer dbus, so we should wait until newer skype is released that supports newer dbus.
i'd like to add my thanx here, too - kopete from trunk is cool. but won't we run into trouble when it gets ported to Qt >4.x?

I think they're going to maintain qt 3.x version during a time. And I think they're going to start porting it to qt 4 at the same time in another branch, so I think we're not going to have problems in at least a while.

superstoned · Post by **superstoned** » Wed Dec 21, 2005 7:24 pm

great