Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[gentoo-dev] LDFLAGS & KDE ebuild

22 views
Skip to first unread message

Troy Dack

unread,
Apr 13, 2004, 9:50:10 AM4/13/04
to
Hi peoples,
I'm presently putting together an ebuild for synce-kcemirror
(http://synce.sourceforge.net/synce/kde/pdamirror.php).

For some reason the ./configure does not seem to pass on to ld that the
kde libs are in a non-standard location, resulting in:

/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lkdeprint

I've managed to get it to build and install, however I don't think the
following is really the best:

src_compile() {
cd ${S}
LDFLAGS="-L/usr/kde/cvs/lib" econf || die
LDFLAGS="-L/usr/kde/src/lib" emake || die
}

So, how can I:
a) work out where the kde libs are installed
b) pass this nicely to ./configure and make

Any advice greatly appreciated.

Thanks

--
Troy Dack Gentoo moves pretty fast; if you don't stop and
t...@gentoo.org look around once in a while, you could miss out.

Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4D90BE3C
Key fingerprint = 1F3D 6C15 16AA 09D5 0C96 92E5 FD89 16F9 4D90 BE3C


--
gento...@gentoo.org mailing list

Caleb Tennis

unread,
Apr 13, 2004, 10:00:19 AM4/13/04
to
On Tuesday 13 April 2004 08:48 am, Troy Dack wrote:
> So, how can I:
> a) work out where the kde libs are installed
> b) pass this nicely to ./configure and make

Use the ./configure --prefix /path/to/kde/blah/foo option

Or, better yet, use the functions in the kde.eclass.

Caleb

--
gento...@gentoo.org mailing list

Ned Ludd

unread,
Apr 23, 2004, 3:20:07 PM4/23/04
to
On Tue, 2004-04-13 at 09:48, Troy Dack wrote:
> Hi peoples,
> I'm presently putting together an ebuild for synce-kcemirror
> (http://synce.sourceforge.net/synce/kde/pdamirror.php).
>
> For some reason the ./configure does not seem to pass on to ld that the
> kde libs are in a non-standard location, resulting in:
>
> /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lkdeprint
>
> I've managed to get it to build and install, however I don't think the
> following is really the best:
>
> src_compile() {
> cd ${S}
> LDFLAGS="-L/usr/kde/cvs/lib" econf || die
> LDFLAGS="-L/usr/kde/src/lib" emake || die
> }


Please never completely override LDFLAGS= like in the above example,
the hardened use makes heavy use of them.
Instead please try.

inherit flag-o-matic

src_compile() {
append-ldflags -L/usr/kde/cvs/lib
...
..
.
}

# or the likes..
Thanks.

> So, how can I:
> a) work out where the kde libs are installed
> b) pass this nicely to ./configure and make
>
> Any advice greatly appreciated.

KDE/QT really needs to be careful with linking. I've done a rather quick
audit of ELF RPATH and KDE/QT is keeps RPATH's set to /var/tmp/portage*.
This is very bad.. If say a user would do something as silly as symlink
/var/tmp and /tmp then complete control of the system could be gained by
almost any user with half a brain. So for example.. If one were to run
this script and find anything printed to the screen then she/he can kiss
her/his sweet arse goodbye.
http://dev.gentoo.org/~solar/audit/audit.rpath 'man 1 ld' for more info

>
> Thanks
--
Ned Ludd <so...@gentoo.org>
Gentoo Linux Developer

signature.asc

Spider

unread,
Apr 23, 2004, 4:30:15 PM4/23/04
to
begin quote
On 23 Apr 2004 15:09:26 -0400
Ned Ludd <so...@gentoo.org> wrote:

>
> KDE/QT really needs to be careful with linking. I've done a rather
> quick audit of ELF RPATH and KDE/QT is keeps RPATH's set to
> /var/tmp/portage*.
> This is very bad.. If say a user would do something as silly as
> symlink /var/tmp and /tmp then complete control of the system could be
> gained


actually its not overly silly thing to do (symlink or bind mount) as the
things in /var/tmp/portage arent really persistant between reboots (as
the data in /var should be) . So from a users perspective it might even
be seen as a "good thing(tm)".

So yes, a check on the RPATH is good.

//Spider

--
begin .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

Caleb Tennis

unread,
Apr 23, 2004, 4:50:08 PM4/23/04
to
> Ned Ludd <so...@gentoo.org> wrote:
> > KDE/QT really needs to be careful with linking. I've done a rather
> > quick audit of ELF RPATH and KDE/QT is keeps RPATH's set to
> > /var/tmp/portage*.
> > This is very bad.. If say a user would do something as silly as
> > symlink /var/tmp and /tmp then complete control of the system could be
> > gained

Since 3.3.0, I've modified Qt so as not to have RPATH for the uic program.
It's the only program I was aware of that was getting it set. Do you have
information of more utilities setting it?

Ned Ludd

unread,
Apr 23, 2004, 6:10:23 PM4/23/04
to
On Fri, 2004-04-23 at 16:24, Spider wrote:
> begin quote
> On 23 Apr 2004 15:09:26 -0400
> Ned Ludd <so...@gentoo.org> wrote:
>
> >
> > KDE/QT really needs to be careful with linking. I've done a rather
> > quick audit of ELF RPATH and KDE/QT is keeps RPATH's set to
> > /var/tmp/portage*.
> > This is very bad.. If say a user would do something as silly as
> > symlink /var/tmp and /tmp then complete control of the system could be
> > gained
>
>
> actually its not overly silly thing to do (symlink or bind mount) as the
> things in /var/tmp/portage arent really persistant between reboots (as
> the data in /var should be) . So from a users perspective it might even
> be seen as a "good thing(tm)".

Perhaps our install guides should updated to reflect this should never
be done.

>
> So yes, a check on the RPATH is good.
>
> //Spider
--

signature.asc

Ned Ludd

unread,
Apr 23, 2004, 6:30:11 PM4/23/04
to
On Fri, 2004-04-23 at 16:43, Caleb Tennis wrote:
> > Ned Ludd <so...@gentoo.org> wrote:
> > > KDE/QT really needs to be careful with linking. I've done a rather
> > > quick audit of ELF RPATH and KDE/QT is keeps RPATH's set to
> > > /var/tmp/portage*.
> > > This is very bad.. If say a user would do something as silly as
> > > symlink /var/tmp and /tmp then complete control of the system could be
> > > gained
>
> Since 3.3.0, I've modified Qt so as not to have RPATH for the uic program.
I'm not so sure about that..

solar@simple solar $ readelf -d /usr/qt/3/lib/libqt-mt.so.3 | grep RPATH
0x0000000f (RPATH) Library rpath:
[/space/tmp/portage/qt-3.3.1-r1/work/qt-x11-free-3.3.1/lib]

solar@simple solar $ qpkg -f /usr/qt/3/lib/libqt-mt.so.3
x11-libs/qt *

solar@simple solar $ emerge -pv qt
[ebuild R ] x11-libs/qt-3.3.1-r1 -cups -doc -firebird -gif -icc
-ipv6 +mysql -nas -odbc +opengl -postgres -sqlite +xinerama +zlib 0 kB


>
> It's the only program I was aware of that was getting it set. Do you have
> information of more utilities setting it?

The list is fairly large..
Best to test on your own local boxes.

The packages that are probably most at risk can be listed by
preforming the following commands.

wget http://dev.gentoo.org/~solar/audit/ls.rpath
sh ls.rpath | grep tmp


> Caleb
>
> --
> gento...@gentoo.org mailing list

signature.asc
0 new messages