"Gary V. Vaughan" wrote:
>
> Since we are trying to make things work like UNIX here, I think that the dlls
> should probably be installed to $libdir. The problem that needs solving is
> how to teach the executable to find its dlls.
>
> Unfortunately this probably comes dow to wrapper scripts,
On Tuesday 05 June 2001 3:35 pm, Robert Collins wrote:
> dlpreopen generates a list of symbols - say
>
> extern char _imp__free;
>
> extern char nothing;
> extern char printf;
> extern char realloc;
>
> from the source library - cyghello-2.dll
>
> "nothing" here should be extern __declspec(dllim
Since we are trying to make things work like UNIX here, I think that the dlls
should probably be installed to $libdir. The problem that needs solving is
how to teach the executable to find its dlls.
Unfortunately this probably comes dow to wrapper scripts, which is ugly too
=(O|
Bah!
> "Pierre" == Pierre Sarrazin <[EMAIL PROTECTED]> writes:
Pierre> Logically, it is in a Makefile.am file that I would like to
Pierre> ask that a specific library should be static.
If you are trying to build a static library, then simply don't use
libtool for that library. Write `lib_LIBRARI
Pierre:
If you put additional configure.in files in the subdirectories,
you can specify whatever you like in them, and they'll only
affect those subdirectories.
In general you can use one top-level configure.in if everything
is the same, if not you just need to have separate configure
scripts. T
>> "Lars J. Aas" <[EMAIL PROTECTED]> writes:
> Another digression; I'd like to know what you meant with the "mostly non
> issue" comment.
I forgot there's still a "Professional Edition" of Coin, and that even
LGPL Coin is anything but dead. My mistake.
WRT ABI compatibility, it should be
I am autoconfiscating a large source tree with Autoconf (2.13),
Automake (1.4) and Libtool (1.3.5) on a GNU/Linux system.
In this tree, there are subtrees that constitute the sources for
shared libraries. Other subtrees should give static libraries
because they will never be needed in shared for
On Thu, Jun 07, 2001 at 11:30:22PM +0200, Marcelo E. Magallon wrote:
: needs a way to be able to set the soname. Yes, this is bad in general.
: It defeats the whole purpose of libtool, but the problem is that Mesa
: is providing another version of an existing library. I can imagine
: things
I sent the message below to bug-libtool about a week ago, no reply.
Does anyone have solutions, answers, ... ?
Danny
-- Forwarded by Danny Backx/U27113/KB/KredAlm on
06/08/2001 11:55 AM ---
[EMAIL PROTECTED] on 06/02/2001 07:30:00 PM
To:
Does anyone know about LynxOS 2.3 and it's support within libtool?
This platform seems to miss in the platform list in README
and so I guess it's not supported.
The following error was reported when someone tries to build
LessTif (based on libtool 1.4) on that platform:
Making all in Xm-2.0
make
On Jun 7, 2001, [EMAIL PROTECTED] wrote:
> Now it's really quick. I'm worried that doubling is too fast but I
> think we should be OK.
On the contrary. I'm wondering if we shouldn't just choose a
relatively large number, say 32Kb, check that broken seds will break
with such a long line, and wa
11 matches
Mail list logo
