Path bug
Brought to you by:
wiecko
Menu
▾
▴
#20 Path bug
As brought up on the gentoo forums:
I heard of it but which one to use in this case (Sorry
for long post but I am attaching a log)
Is it the inherit thing like: inherit kde-meta ?
Will see what I can do here and get it to work. ( I
removed usr prefix for install but still)
likely looking for: ksharedptr.h
the ./config script is to blame not looking for gentoo
location:
Quote:
root@tux local # locate ksharedptr.h
/usr/kde/3.3/include/ksharedptr.h
I may need to update paths
Quote:
configure: 25186: /usr/kde/3.3.2-r7/include/ksharedptr.h
configure: 25186:
/usr/kde/3.3.2-r7/include/kde/ksharedptr.h
configure: 25186: /usr/kde/3.3.2-r7/ksharedptr.h
configure: 25186: /usr/lib/kde/include/ksharedptr.h
configure: 25186: /usr/local/kde/include/ksharedptr.h
configure: 25186: /usr/local/include/ksharedptr.h
configure: 25186: /usr/kde/include/ksharedptr.h
configure: 25186: /usr/include/kde/ksharedptr.h
configure: 25186: /usr/include/ksharedptr.h
configure: 25186: /opt/kde3/include/ksharedptr.h
configure: 25186: /opt/kde/include/ksharedptr.h
configure: 25186: ./ksharedptr.h
configure: 25186: /usr/qt/3/include/ksharedptr.h
I have found the problems it seems to be path issues
either by the installer of the program or gentoo
differences where libs are placed!
root@tux klearnnotes2-1.2 # locate kdewidgets.la
/usr/kde/3.3/lib/kde3/plugins/designer/kdewidgets.la
root@tux klearnnotes2-1.2 # locate ksharedptr.h
/usr/kde/3.3/include/ksharedptr.h
root@tux klearnnotes2-1.2 # ldconfig
Do not know who's bug it is or none standard gentoo lib
location program needed for kde headers. The paths
below are gentoo's the program did not look into them.
Code:
/usr/kde/3.3/lib/kde3/plugins/designer/kdewidgets.la
/usr/kde/3.3/include/ksharedptr.h
/usr/kde/3.3/lib/libkio.la
Solved it by relinking it all "work around". Going
contact the author too and let him / her know.
Compiling now.
Logged In: YES
user_id=879528
Mickey,
Thank you for your report. I'm sorry you faced this problem.
If I get it right, you tried to compile kln2-1.2 and the
configure script failed, because it couldn't find the following:
> /usr/kde/3.3/lib/kde3/plugins/designer/kdewidgets.la
> /usr/kde/3.3/include/ksharedptr.h
> /usr/kde/3.3/lib/libkio.la
The --includedir and --libdir configure arguments may help
here - see 'configure --help'. In the above case the
following should help:
--includedir=/usr/kde/3.3/include
--libdir=/usr/kde/3.3/lib:/usr/kde/3.3/lib/kde3/plugins/designer
There is no way to really know where these libs are placed -
every single distro and even every single user can have it
somewhere else. These arguments of './configure' are
provided exactly for the situation like this one.
Alternatively, you could set KDEDIR to /usr/kde/3.3 (which
has the advantage of saving you typing the args for
configure each time).
'setenv KDEDIR /usr/kde/3.3' in tcsh and alike, or
'export KDEDIR=/usr/kde/3.3' for sh/bash.
I know, you have already solved the problem for yourself (as
far as I understand, by hand-editing the './configure'
script), but could you please check and let me know, whether
adding --includedir and --libdir or setting KDEDIR (or both)
helps?
Regards,
Marek
BTW: of course, I will add the /usr/kde/3.3 location for the
libs search path in next release. The question is: is there
really a patch needed for the last release, or can users
survive with the above solutions.
I don't know about gentoo: did you try to make some kind of
rpm-like package, and the script has to work by calling
./configure without arguments? If this is the case, let me
know -- this really requires a patch now.
M.
Logged In: YES
user_id=1183518
Hello wiecko,
> Mickey,
> Thank you for your report. I'm sorry you faced this problem.
> If I get it right, you tried to compile kln2-1.2 and the
> configure script failed, because it couldn't find the
following:
> /usr/kde/3.3/lib/kde3/plugins/designer/kdewidgets.la
> /usr/kde/3.3/include/ksharedptr.h
> /usr/kde/3.3/lib/libkio.la
Correct it seems it could not find where all the contents of
"/usr/kde/3.3" is. What I did was made symbolic links to
them. (By taking the shortest path based on config.log in
theory it allowed to use few different paths but said "I
took /usr/kde/) It is a bit confusing to tell you exactly
what I did but will try.
the contents of "/usr/kde/3.3/" was relinked:
something like (ln -s)
from:
/usr/kde/3.3/bin
/usr/kde/3.3/env
/usr/kde/3.3/etc
/usr/kde/3.3/include <-- very important has all the files
otherwise alone it complained of other missing files.
/usr/kde/3.3/lib
/usr/kde/3.3/share
/usr/kde/3.3/shutdown
(Again the path linked to was selected by me because i knew
./configure will look into it. It seemed the shortest
workaround too).
linked to:
/usr/kde/bin
/usr/kde/env
/usr/kde/etc
/usr/kde/include <-- very important has all the files
otherwise alone it complained of other missing files.
/usr/kde/lib
/usr/kde/share
/usr/kde/shutdown
> Alternatively, you could set KDEDIR to /usr/kde/3.3 (which
> has the advantage of saving you typing the args for
> configure each time).
> 'setenv KDEDIR /usr/kde/3.3' in tcsh and alike, or
> 'export KDEDIR=/usr/kde/3.3' for sh/bash.
> I know, you have already solved the problem for yourself (as
> far as I understand, by hand-editing the './configure'
> script), but could you please check and let me know, whether
> adding --includedir and --libdir or setting KDEDIR (or both)
> helps?
I could do that but for a user it complicates things as it
is. Really here is not your fault because "Distro's" decide
to place it in none standard locations from the next one and
so on.
It was not hand edited but instead relinked to fool
"configure" into taking it.
> BTW: of course, I will add the /usr/kde/3.3 location for the
> libs search path in next release. The question is: is there
> really a patch needed for the last release, or can users
> survive with the above solutions.
Maybe the most advanced users could but it is better if it
finds it on its own. With hope gentoo does not modify again
the paths. Otherwise the patch will break again.
> I don't know about gentoo: did you try to make some kind of
> rpm-like package, and the script has to work by calling
> ./configure without arguments? If this is the case, let me
> know -- this really requires a patch now.
Gentoo does not use rpm's or apt-get but it uses ebuilds.
I made an ebuild which has issues that when I have sandbox
on it tells me "access" violation because it tries to
install outside of sandbox. That problem is likely mine, not
the program or gentoo's ebuild program "portage". I turned
off the -sandbox to let the program install and it works! (-
midi probably my card has no realtime support for it.)
You will see the part where it configures econf= configure
emake = make einstall = install and you could add variables
which i do not know all of them yet.
The ebuild looks something like below (But got to warn
anyone reading this, this ebuild was made by me and is
extremly extremly buggy but for purposes to show wiecko how
it looks like going be reposted). Anyone that tries to use
it has been warned of possible toast to a stable box! But I
had no problems though with it aside from sandbox.
Hope I made sense speaking directly is easier then typing :-)
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public
License v2
IUSE=""
DESCRIPTION="KLearnNotes2 is a program which can help you
learn music notes' names fast and easily.In future it is
planned to train music key signatures, guitar fretboard and
other things. "
HOMEPAGE="http://www.gnu.org/software/electric/electric.html"
SRC_URI="mirror://sourceforge/klearnnotes2/${P}.tar.bz2"
RESTRICT="nomirror"
LICENSE="not sure likely gpl-2"
SLOT="0"
KEYWORDS="x86"
DEPEND=">=x11-libs/qt
>=kde-base/kdelibs
>=media-libs/tse3"
RDEPEND=""
src_compile() {
econf || die "./configure failed"
emake || die
}
src_install() {
make install || die
dodoc ChangeLog COPYING README
}
Logged In: YES
user_id=1183518
"HOMEPAGE="http://www.gnu.org/software/electric/electric.html"
the homepage is my mistake in the ebuild sorry!
Logged In: YES
user_id=1183518
K, I have tested without the workaround:
--includedir=/usr/kde/3.3/include
--libdir=/usr/kde/3.3/lib:/usr/kde/3.3/lib/kde3/plugins/designer
indeed error remains:
in the prefix, you've chosen, are no KDE headers installed.
This will fail.
So, check this please and use another prefix!
so i removed:
--includedir=/usr/kde/3.3/include
--libdir=/usr/kde/3.3/lib:/usr/kde/3.3/lib/kde3/plugins/designer
Decided to just keep econf with the workaround as below.
(The ebuild probably is finally complete as no more
sandbox issues. except the future ./config fix). So anyone
could try it but no warranty!
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public
License v2
IUSE="kde"
inherit kde-functions
DESCRIPTION="KLearnNotes2 is a program which can help you
learn music notes' names fast and easily.In future it is
planned to train music key signatures, guitar fretboard and
other things. "
HOMEPAGE="http://klearnnotes2.sourceforge.net/"
SRC_URI="mirror://sourceforge/klearnnotes2/${P}.tar.bz2"
RESTRICT="nomirror"
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="x86"
DEPEND=">=kde-base/kdelibs
>=media-libs/tse3"
DEPEND="kde? ( >=kde-base/kdelibs-3 )"
RDEPEND="${DEPEND}"
need-qt 3
src_compile() {
econf || die "./configure failed"
emake || die
}
src_install() {
make install DESTDIR=${D} || die
dodoc AUTHORS INSTALL NEWS README TODO
}
Logged In: NO
I'm not sure if this is caused by a bug in configure or not.
The 'checking if UIC has KDE plugins available' test creates
a actest.cpp file and the test fails because grep can't find
the string 'klineedit' in it. I've looked into the file and
it has one line:
testInput = new KLineEdit( this, "testInput" );
Should there actually be a lowercase klineedit in the file
or was the lower casing in the grep command used by
accident? I've just changed the grep call in configure and
it doesn't seem to have hurt any...