and I have taken this under advisement, and plan to
start the transition to reloadable objects after the dust on 2.0 has
settled.
Thanks for persevering with us.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass
Please report bugs to <[EMAIL PROTECTED]>, along with the verbose
output of any failed test groups, and the output from `./libtool
- --help.'
- --
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker
trapped tarball.
* Fix hanging bug on MinGW.
Please report bugs to <[EMAIL PROTECTED]>, along with the verbose
output of any failed test groups, and the output from `./libtool --help.'
Enjoy!
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http
tatic do not do any dynamic linking at all
-lt-staticdo not do any dynamic linking of libtool libraries
(We can keep -all-static as an alias to -static).
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.
Hi Bob!
Bob Friesenhahn wrote:
> On Tue, 2 Nov 2004, Gary V. Vaughan wrote:
>
>>
>> Unless someone shouts me down, then according to the principle of least
>> surprise, I'm inclined to change the semantics to:
>>
>> -static do not do any dynamic l
libm.so.6 => /lib/tls/libm.so.6 (0x40039000)
> libc.so.6 => /lib/tls/libc.so.6 (0x4005d000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)
>
> So libswish-e is linked statically there.
But would you be unhappy if libtool took -stat
Replying to myself after reading more of the thread...
Gary V. Vaughan wrote:
>
> Bob Friesenhahn wrote:
> >
> > The main purpose of building a completely static program is to satisfy
> > security or system bootstrap requirements (/usr partition not mounted).
> >
ld become much easier if the
autotools merged into a single cooperative package to fix this kind of thing.
There was some loose agreement that this would happen someday :-(
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.
making `-static' choose which system libraries to link dynamically
based on some other method than whether or not they have a .la file attached?
`-lt-static' was still-born, lets pretend I never said that ;-)
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
> 1. use -static
> 2. don't want fully static
> 3. would have a hard time coping with the change
>
> :-) Cheers - Bruce
What he said :-) As long as they are `few'. I happen to think that they
really are.
And for the very few who really really want fully static, they can
really know
they want to trade off deployability against a static only link.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~
Hi Bill,
Bill Moseley wrote:
> On Tue, Nov 02, 2004 at 12:39:10PM +0000, Gary V. Vaughan wrote:
>
>>>2) Is there a "standard" way to run configure that should build a
>>>completely static binary?
>>
>>Assuming libtool is doing all your linking:
>&
Hi Peter,
Peter O'Gorman wrote:
> Gary V. Vaughan wrote:
>
>> Considering Bob's posts about how static linking against system libraries
>> gets you a binary that might stop working if you move it to another
>> similar version, or upgrade your system...
ng libtool (and
thus there is a libxml2.la file present), where libz is not.
Yep!
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Au
e. Arguably libltdl/Makefile.am has
ancestry from before I joined libtool, but the clause was already present
in the libtool license when libltdl was added, so there is no
problem in adding the clause back in.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED
idity with -static/-all-static choosing static files based
on .la file presence.
9. Cross compilation test cases.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www
parallel maintain
and/or generate both shell and C versions at all.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_
te the testsuite post-2.0.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
si
he code is still not very mature.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autoboo
that already. Silly me.
I'll have some more coffee before I post again :-@
> A week ago you said that this particular issue was not critial
> enough to be considered for 2.0.
I don't want to hold 2.0 up while we wait for it. But if a fix arrives in
time, then that is a good t
ment project in sourceforge CVS.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autoboo
Hi Ralf,
Ralf Wildenhues wrote:
> Missed that one reading the first time..
>
> * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET:
>
>>>3. Try and recruit some people to translate the docs?
>>
>>I think there is already a GNU translation project to
e the resulting output file without
restriction.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.
On second thoughts, why not take this opportunity to unify the license
exception between libtool and automake so we can share code more easily?
Gary V. Vaughan wrote:
Alexandre Duret-Lutz wrote:
"Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
[...]
Paul> Would you use the ex
Hey Bob!
Bob Friesenhahn wrote:
> On Tue, 9 Nov 2004, Gary V. Vaughan wrote:
>
>> Bob Friesenhahn wrote:
>>
>>> There may be some other existing small shell/scripting implementation
>>> which please Unix programmers but are small enough to embed in other
>
Peter O'Gorman wrote:
> Hi Gary,
Howdy!
> Gary V. Vaughan wrote:
>>> Post 2.0:
>
>
>>> 1. Generate a libtool.m4 from a bunch of individual file, one per
>>> platform, to make the job of a "platform maintainer" easier and make it
>>
Bob Friesenhahn wrote:
> On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
>
>>>
>>> The main issue I see with using embryo (or small, or Java) or any other
>>> byte-code/VM based machine is that it seems to make it much more
>>> difficult for the end-user to f
le language, but I would definitely like to explore the
idea of replacing the creaky old ltmain.sh code :-)
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/li
Ralf Wildenhues wrote:
> * Gary V. Vaughan wrote on Wed, Nov 10, 2004 at 02:25:11PM CET:
>>Gah, perl? Blech. XML? Bah! Choke...
>>
>>
>
> *snip*
>
>>There... I've got it off my chest, and feel much better now :-)
>
>
> /me agrees on ev
Daniel Reed wrote:
On 2004-11-09T18:19-, Gary V. Vaughan wrote:
) Ralf Wildenhues wrote:
) > * Gary V. Vaughan wrote on Tue, Nov 09, 2004 at 03:24:25PM CET:
) >>3.5. While we are there, maybe internationalise libltdl?
) > Please don't. If you do, make it possible to have zer
Paul Eggert wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
However, even though our intentions are good, and we are merely
clarifying the existing spirit of the exception clauses we have used
all along, is it okay to just edit the license of existing files without
explicit
Paul Eggert wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
>
> Was anybody unhappy with the exception wording in my last post in the
> thread? If not we can start from there.
I worry that it's too generous, because it means that if the package
uses the .m4 f
use.
"or any derived output" is a lame attempt to allow tools such as
aclocal (without singling out aclocal) to preprocess the file,
as long as the intent is to build a configure script.
I prefer my wording :-)
Bruce's would be kinda cool too. But frankly, I'd be flabb
Alexandre Duret-Lutz wrote:
"Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> The use of GNU Autoconf is to prevent someone creating their
Gary> own tool and calling that Autoconf to circumvent the license.
I don't have a problem with GNU Autoconf, only
you may distribute this file and the derived files
Paul> for that purpose, under the same terms that you use for
Paul> the rest of the package.
[...]
President Eggert, you have my vote!
Seconded :-)
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scien
Paul Eggert wrote:
"Gary V. Vaughan" <[EMAIL PROTECTED]> writes:
Now for the note to the FSF that explains why we need it... here
is a first cut to get the ball rolling:
That looks fine to me. Thanks.
Okay, there have been no corrections or objections in the last 24 hours...
Whe
Hi Albert!
Albert Chin wrote:
> On Wed, Nov 10, 2004 at 03:43:48PM +, Scott James Remnant wrote:
>
>>On Tue, 2004-11-09 at 14:24 +, Gary V. Vaughan wrote:
>>
>>
>>>6. Absorb the functionality of the aberration called pkg-config. Libtool
>>>
Stepan Kasal wrote:
> Hello,
Hi Stephan!
> On Fri, Nov 12, 2004 at 10:25:32AM +, Gary V. Vaughan wrote:
>
>>Where do we send it? Direct to rms?
>
>
> I'd say assign or copyright-clerk are better (at gnu.org, of course).
Those aren't the actual legal g
eryone if libtool could
extract linkflags like above without the -n -o sleight of hand. With
luck, we could persuade the pkg-config folks to use that to pass back
a correct link line that won't hose their users' builds.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECT
altered by the
user to give things a hope of linking? ;-)
But seriously, why would you install a .pc using library, and then
alter the installed .pc file?
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kick
Hi Jacob,
Jacob Meuser wrote:
On Sun, Nov 14, 2004 at 05:09:08PM -0500, Daniel Reed wrote:
On 2004-11-14T14:56-0600, Bob Friesenhahn wrote:
) On Sun, 14 Nov 2004, Gary V. Vaughan wrote:
) > $ PKG_CONFIG_PATH=/opt/libgdiplus10/lib/pkgconfig
) You seem to be a victim of a package install where ev
Hi Jacob,
Jacob Meuser wrote:
On Sun, Nov 14, 2004 at 09:04:31PM +, Gary V. Vaughan wrote:
Hi Bob!
Bob Friesenhahn wrote:
You seem to be a victim of a package install where every package has
used its own unique installation prefix. It seems to me that most
systems use just one or two
Ralf Wildenhues wrote:
I've been away for a few days..
* Gary V. Vaughan wrote on Sun, Nov 14, 2004 at 09:44:19PM CET:
Scott James Remnant wrote:
They're both trying to deal with platforms like Solaris that don't have
a needed-following link loader.
That's a good idea, if we
any dependency info...
Agreed. We would only drop the deplibs when we know the linker will
handle it. The only difference to the user is that they will see much
shorter linker calls if they are building on a host that can handle it.
Everything is remains as is!
Cheers,
Gary.
--
start setting link_all_deplibs=no in
HEAD for platforms that we can prove will support it. Ideally,
the GNU ld case should be keyed off `ld --version` so that we
don't break old dists, but other hosts can probably be taken from
$host_os version quite safely.
Cheers,
Gary.
--
Gary V. V
atforms, set link_all_deplibs to 'no' for both C++ and
+ other compilers.
+ * NEWS: Updated.
Bob's second point needs addressing first, IMHO. I think the
-rpath stuff will come out in the wash provided we are careful.
Either way, this is a deep change for HEAD only.
Cheers,
Bob Friesenhahn wrote:
On Mon, 15 Nov 2004, Gary V. Vaughan wrote:
Bob Friesenhahn wrote:
Doesn't this patch cause Linux to be more equal than other operating
systems, thereby causing free applications to be developed which won't
work anywhere else?
No, it just shortens the link line on
Bob Friesenhahn wrote:
On Wed, 10 Nov 2004, Gary V. Vaughan wrote:
It wouldn't be at all difficult to have 'libtoolize --ltdl
--disable-nls' install a non-internationalised libltdl minus message
catalogues into a parent package. But yes, we would have to take care
to do it
problem.
That is what my tests checks for). For this I had to create a variant
*snip*
I agree with your view of things. I think we should allow this to be
done.
Gary, you did the whole bootstrap reorganization. Is anything close to
this possible?
The theory:
It is my belief that an actual link
the
>> Bob> AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac.
>>
>>IMHO it's a bug in whatever let you think aclocal would honor
>>AC_CONFIG_MACRO_DIR to way you thought. It certainly isn't the
>>Automake manual.
>>
>>See also
>> http://l
Hallo Ralf,
Ralf Wildenhues wrote:
> C'mon Gary, two questions: is it *possible* to provide the old behavior
> without too much pain?
I can't think of a way to do it cleanly :-( But I have no objections in
principle. How much machinery is there to make the config.status parts
o
have branch-2-0 in a releasable state. Guess we're not quite
as close to a 2.0 release as I'd hoped :-(
Yes, please revert --patch-68 from branch-2-0.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-a
ool. Users
> should only have to be confronted with the libtool script. Just give us
> _one_ consistent interface please.
No, they should not, and are not. Nor should grepping the libtool script,
or .la files be part of the user interface to Libtool. We just need to
figure out which p
Hi Kevin,
Kevin P. Fleming wrote:
> Gary V. Vaughan wrote:
>
>> Sander, if you want to check whether a particular library is shared,
>> we should be able to write a macro for you to figure that out without
>> actually needing to roll and run an entire libtool script. Or
K_IFELSE instead/as well.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
;s configure.ac and rerun the same libtool the developer
used to minimise the upgrade work you have to put in.
I have not seen any arguments that make me think that libtool parallel
installs are a bad idea in principle. Several good arguments as to
why the implementation I backed out of the relea
testsuite for this condition.
Cheers,
Gary.
Peter O'Gorman wrote:
> This mail is an automated notification from the support tracker
> of the project: GNU Libtool.
>
> /**/
> [support #100058]
Hi Peter!
Peter O'Gorman wrote:
> Gary V. Vaughan wrote:
>> Not meaning to seem overly pedantic, but could you enumerate the
>> release(s) you tested when you decided that it was safe to close this?
>
> I fixed this particular bug with:
>
<http://savannah.gnu.org
mp;item_id=103603>
Okay, thanks.
I just commited libtool--release--2.0--patch-87 to fix your $SHELL bug
btw, so things should be somewhat saner for you now.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
Peter O'Gorman wrote:
> Gary V. Vaughan wrote:
>> Peter O'Gorman wrote:
>>
>>> I again managed to make a commit and forgot to do it properly (so no
>>> mail was sent to libtool-commits), so I filed a support request to get
>>> commit mails handle
Peter O'Gorman wrote:
libtool todo list
> [[snip]]
Rewrite everything in perl, and use xml and xslt just to annoy Gary.
I quit!
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu
d property.
"degrading gracefully" is the term I have always used. Open Source
is almost always an evolutionary process, so we can only take it one
step at a time... best of all, if we step out of line, it is usually
easy to get back on track and try again with something else :-)
Cheers,
Gary V. Vaughan wrote:
Peter O'Gorman wrote:
libtool todo list
> [[snip]]
Rewrite everything in perl, and use xml and xslt just to annoy Gary.
I quit!
But seriously, thanks for working through that convoluted thread!
I owe you a(nother) beer.
Do you want me to copy it into CVS TODO
Ralf Wildenhues wrote:
* Gary Kumfert wrote on Fri, Dec 17, 2004 at 12:17:17AM CET:
Wasn't libtoolize supposed to update the libtool.m4 file?
I'll leave this question for somebody else to answer.
Okay, I'll bite :-)
Yes, libtoolize should have updated libtool.m4. However, there
y
done at creation time.
2. Shipping a script to optionally trawl the filesystem and normalize
installed .la files (and add a pathsnormalized decl) at libtool 'make
install' time would save time for subsequent libtool calls.
3. I wonder how much of the normalization we could
> do '#ifdef PIC' when surely '#ifdef __PIC__' would be more reliable.
Libtool supports plenty more compilers than just gcc.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Ha
b/libfoo.la
HTH,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: Open
try and make a patch for branch-2-0 and HEAD today, and we can backport
that to branch-1-5 if necessary after approval.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu
Gary V. Vaughan wrote:
> Peter O'Gorman wrote:
> > I question that we can rely on tar being installed, although I have not
> > come across a system where it isn't.
>
> Maybe I should add a --no-tar option to fallback to 'cp -p'
> to cover that eventual
Peter O'Gorman wrote:
> Hi Gary,
Hallo!
> I question that we can rely on tar being installed, although I have not
> come across a system where it isn't. Please backport things to
> branch-1-5, it is apparently the branch that never dies, no matter how
> much we want it
t
> be helpful!
Argh, the attached wrapper appears to be clearing LD_LIBRARY_PATH. Are
you using fast-install mode (./configure --enable-fast-install)? Does
the autogen binary install without needing to be relinked? What architecture
are you running all of this on at the moment?
Cheers,
all-files
>
> However, there's no such target in libltdl/Makefile.am (nor
> libltdl/Makefile). Was install-local-data meant, instead?
D'oh! Missed that when backporting. Thanks, should be fixed in CVS
now, by 121-gary-remove-local-install-files-call.patch.
Cheers,
Gary
701 - 772 of 772 matches
Mail list logo
