libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SCO/bugfix patch 7 of 10: Improve SCO platform support


From: Kean Johnston
Subject: Re: SCO/bugfix patch 7 of 10: Improve SCO platform support
Date: Wed, 09 Nov 2005 01:18:27 -0800
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Well, I believe the SCOABSPATH is not only ugly, but also broken (from a
libtool perspective): if you have a package which creates two libraries,
one depending on the other, your uninstalled library will link against a
previous installed version, if that exists.  While testing, this is
wrong.
I agree its ugly but its a necessary evil. All the point you raise
about it being generalized are valid, and I will help out as much
as I can to make that happen. But its going to take a while for
2.0 to be adopted. Meanwhile, I believe a new release of 1.5 is
imminent, and people are likely to upgrade to that, and it will be
around for a while. The problem is, as things currently stand,
libtool will create shared libraries that expose a severe security
flaw.

Picture this. Someone compiles KDE for their box. It creates
a bunch of shared libraries using libtool. kterm is setuid root.
A user can now trivially get root on that box if they are running
an older release of SCO.

The intent of SCOABSPATH was admittedly a little selfish. I would
*really* like it if for once, just once, I can pull down a package
and do a ./configure; make and have it do the right thing. If I
have to maintain my own patched libtool I have to re-autoconf the
thing and on some packages, that is very painful.

I would really *really* beg that you let me keep the SCOABSPATH
thing in as it stands. For normal usage, it doesn't interfere
with anybody or anything. Its localized to an OS that a relatively
few number of people care about. Its primary user is me, who is
pendantic in teh extreme about compiling packages. For example,
I always compile twice: first time I do a make install, then I
recompile with SCOABSPATH set and to a make install DESTDIR=/whatever
for packaging and production. It is by far the safest way to fly.
When the more generalized work can be done for 2.0, and more
packages adopt it, maybe I wont have to do that.

libtool is meant to be a tool for developers. The reality is,
there are two of us at SCO that provide 90% of the open source
stuff for our platform. I tend to focus on stuff that makes it
in-product, and Ron Record does the stuff for our "Skunkware"
collection of open source tools. Between the two of us, you've
covered about 50% of the users of libtool on SCO platforms :)
SCOABSPATH as it currently stands really helps us immensely.

Also, with due respect, if you are going to reject the patch
just becuase of the SCOABSPATH thing can I please ask you to
reconsider? It may look unclean but in reality its really
pretty simple ... insert a libtool variable into another libtool
variable is an environment variable is set. There are far
worse things going on in libtool :)

Kean




reply via email to

[Prev in Thread] Current Thread [Next in Thread]