Hi Enrico,
* Enrico Weigelt wrote on Mon, Sep 26, 2005 at 09:56:27PM CEST:
>
> how does libtool decide whether to link against an .la library
> dynamically vs. statically ?
For a program or a library? Uninstalled or installed library
(see recent bug report of Howard Chu)? On a system with bot
Ralf Wildenhues wrote:
We have better support for sysroot and/or DESTDIR on our TODO list.
Why don't you help us improve and fix libtool? That is bound to be
a lot less work.
*time passes*
http://lists.gnu.org/archive/html/libtool-patches/2005-06/msg00161.html
Oh, you asked before. Why not r
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jacob Meuser wrote:
| I think perhaps you should ask [EMAIL PROTECTED] about this. he might
| be able to explain why -lstdc++ is not implicitly used in `g++ -shared',
| which could give you a good starting point on how to "fix" the
| "problem".
|
I
Now that there are no doubts about the portability of shell functions
(in the sense that there's always a shell on the machine that supports
function ---and maybe the documentation should reflect this), I'm
curious about the support of "return" and "local". Is there anything
known about them? IS
* Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
Hi,
> > how does libtool decide whether to link against an .la library
> > dynamically vs. statically ?
>
> For a program or a library? Uninstalled or installed library
> (see recent bug report of Howard Chu)?
Each of these cases ...
I've now fig
[Cc:-ed to Mark Espie at Jacob's suggestion:
> I think perhaps you should ask [EMAIL PROTECTED] about this. he might
> be able to explain why -lstdc++ is not implicitly used in `g++ -shared'
If you need context, this is the whole thread:
http://thread.gmane.org/gmane.comp.gnu.libtool.general/6671
On 2005-09-22, Peter O'Gorman <[EMAIL PROTECTED]> wrote:
> Do we know what the versions of the OS/gcc are where -lstdc++ is missing? We
> can enplicitly add it (as we did recently for, I think, sunpro c++). Is this
> a gcc bug, or is it by design?
I've only been able to test OpenBSD 3.7 with g++ 3
Hi,
After reading a recent thread on `guile-user', it occurred to me that
`lt_dlopenext ()' doesn't allow to pass information about the version of
a module that is requested.
This is quite unfortunate, especially for Guile, since Guile modules
load C libraries using `dynamic-link' which is roughl
Hi Howard,
* Howard Chu wrote on Tue, Sep 27, 2005 at 12:01:22PM CEST:
> Ralf Wildenhues wrote:
> >We have better support for sysroot and/or DESTDIR on our TODO list.
> >Why don't you help us improve and fix libtool? That is bound to be
> >a lot less work.
> >http://lists.gnu.org/archive/html/li
On Tue, 27 Sep 2005, Howard Chu wrote:
> First of all, my objective - other folks may have their own objectives
> different than this: Build a suite of software that uses shared libraries,
> such that any embedded runpaths only reflect the ultimate install path (e.g.
> /opt/foo/lib) and not any of
Hi Enrico,
* Enrico Weigelt wrote on Tue, Sep 27, 2005 at 03:27:21PM CEST:
> * Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> > > how does libtool decide whether to link against an .la library
> > > dynamically vs. statically ?
> >
> > For a program or a library? Uninstalled or installed librar
Hi Tim,
* Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST:
> On Tue, 27 Sep 2005, Howard Chu wrote:
>
> > First of all, my objective - other folks may have their own objectives
> > different than this: Build a suite of software that uses shared libraries,
> > such that any embedded runpath
Akim Demaille <[EMAIL PROTECTED]> writes:
> Now that there are no doubts about the portability of shell functions
> (in the sense that there's always a shell on the machine that supports
> function ---and maybe the documentation should reflect this),
Yes, it should.
> I'm curious about the suppo
Andreas Schwab <[EMAIL PROTECTED]> writes:
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
>> Assuming you don't need recursion, here's a thought. Use "local", but
>> stick to the convention that all variable names are unique. On
>> systems that don't support "local", define a function named "local"
Paul Eggert <[EMAIL PROTECTED]> writes:
> Assuming you don't need recursion, here's a thought. Use "local", but
> stick to the convention that all variable names are unique. On
> systems that don't support "local", define a function named "local"
> that warns if any of its arguments is a variabl
On Tue, 27 Sep 2005, Ralf Wildenhues wrote:
> Hi Tim,
>
> * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST:
> > I'd like to be able have the embedded runpath be /opt/lib even
> > if I install in /opt/foo/lib. (the package posinstall script would put
> > symbolic links in /opt/lib)
>
> I
On Tue, Sep 27, 2005 at 01:31:37PM +, Olly Betts wrote:
> [Cc:-ed to Mark Espie at Jacob's suggestion:
> > I think perhaps you should ask [EMAIL PROTECTED] about this. he might
> > be able to explain why -lstdc++ is not implicitly used in `g++ -shared'
>
> If you need context, this is the who
17 matches
Mail list logo
