Link your page to a free web survey.
Easy administration to create and modify your questions.
Just give us a try http://osp.net/survey
* This site allows you to create and modify a web survey very easily
* Excellent graphical output of survey responses
* Export your survey information eas
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRef.o
>.libs/
By the way, notice that this is a C++ DLL which is being linked
against a C DLL also built by libtool. The C DLL did successfully
link using libtool. The C DLL is based in part on a libtool
"convenience library".
To be honest, I believe that there are still some run-time issues with
C++ DLLs un
The exact same error message is reported without -shared.
Bob
On 9 Oct 2002, Elizabeth Barham wrote:
> Bob Friesenhahn <[EMAIL PROTECTED]> writes:
>
> > Ideas?
> >
> > g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .
Bob Friesenhahn <[EMAIL PROTECTED]> writes:
> Ideas?
>
> g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
>.libs/Blob.o .libs/BlobRef.o .libs/CoderInfo.o .libs/Color.o .libs/Drawable.o
>.libs/Exception.o .libs/Functions.o .libs/Geometry.o .libs/Image.o .libs/ImageRe
Earnie,
Using libtool from the head of libtool CVS, and test building
ImageMagick under MinGW (MSYS environment), I get multiple-defined
errors when linking the DLL as shown below.
Ideas?
g++ -shared c:/mingw/bin/../lib/gcc-lib/mingw32/2.95.3-6/../../../dllcrt2.o
.libs/Blob.o .libs/BlobRef.o
On Wed, 2002-10-09 at 19:10, Robert Boehne wrote:
> If we added support for library namespace, all of the
> Darwin developers would start developing software with
> Libtool that used it, and therefore wouldn't link on
> other systems, correct? I'm not claiming I have ever
> seen a Mac running X+
* Michel LESPINASSE <[EMAIL PROTECTED]> [20021009 19:57]:
> On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
> > Ok, let me see if I understand this one,
> > under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
> > to the CFLAGS expl
On Wed, Oct 09, 2002 at 06:27:18PM -0500, Robert Boehne wrote:
> Ok, let me see if I understand this one,
> under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
> to the CFLAGS explicitly, and configured with --enable-shared ??
The package adds -prefer-non-pic to the CFLAGS unco
Ok, let me see if I understand this one,
under Linux hppa, (presumably with gcc) user has added -prefer-non-pic
to the CFLAGS explicitly, and configured with --enable-shared ??
What platforms (aside from Alpha & RS/6000) does this work on?
--
Robert Boehne Software Engineer
Ricardo
Benjamin,
If we added support for library namespace, all of the
Darwin developers would start developing software with
Libtool that used it, and therefore wouldn't link on
other systems, correct? I'm not claiming I have ever
seen a Mac running X+ so you'll have to correct me if I'm wrong.
Libt
On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
> I intend to spin a release 1.4.3 this weekend from the branch-1-4
> sources.
There is a bug in libtool 1.4.2 when using -prefer-non-pic on hppa:
libtool does not pass the -fPIC flag, and then the linker complains
about that. Alexand
On Wed, 2002-10-09 at 16:15, Robert Boehne wrote:
> Christoph,
>
> The patch against libtool.m4 is different from what is in
> CVS branch-1-4. Does today's branch-1-4 have the problem
> your patch intends to fix? It appears that this may
> be fixed in CVS.
> If you would, please get Libtool c
Christoph,
The patch against libtool.m4 is different from what is in
CVS branch-1-4. Does today's branch-1-4 have the problem
your patch intends to fix? It appears that this may
be fixed in CVS.
If you would, please get Libtool cvs branch-1-4, if you
don't have access to it for some reason, s
Hi Robert,
On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote:
> I intend to spin a release 1.4.3 this weekend from the
> branch-1-4 sources. Any properly formatted patches will
> be considered for inclusion before the release. I have
> seen a tendency to post patches on any list in
All,
I intend to spin a release 1.4.3 this weekend from the
branch-1-4 sources. Any properly formatted patches will
be considered for inclusion before the release. I have
seen a tendency to post patches on any list in any
format, which makes it more work to get that particular
patch installed i
> > Yes, you already said that. The stuff above is about the libtool 1.4
> > _branch_, while the libtool-darwin patch is in the mainstream
> development tree.
>
> Right, and I have not yet seen anything that said there will be a
> libtool 1.4.3 release, only that there will be a libtool release i
> From: Sascha Schumann <[EMAIL PROTECTED]>
> Date: Wed, 9 Oct 2002 19:49:57 +0200 (CEST)
>
> > Did you send a bug report? Do you have a test case?
>
> I'm sorry, it was noticed by so many people, I supposed it
> would make its way to you.
It's the first I've heard of it. Do you have
On Wed, Oct 09, 2002 at 12:29:44PM -0500, Bob Friesenhahn wrote:
> On Wed, 9 Oct 2002, Guido Draheim wrote:
>
> > > In my experience, the 1.5 code-base is a solid product on systems
> > > supported by 1.4.2, and provided that it is patched and proven to work
> > > under MinGW and Darwin then 1.5
> You want autoconf -f then.
-f, --force consider all files obsolete
We do a ./cvsclean right now for autoconf +2.50 which purges
all generated data. I guess that is basically the same.
> You know, you are typically the kind of people who has valid grieves
> against Au
On Wed, 9 Oct 2002, Guido Draheim wrote:
> > In my experience, the 1.5 code-base is a solid product on systems
> > supported by 1.4.2, and provided that it is patched and proven to work
> > under MinGW and Darwin then 1.5 should be ready to release.
> >
>
> That's another argument. And since it w
Bob Friesenhahn wrote:
> Time spent on libtool 1.4.3 is time spent doing work which must
> either be done a second time, or has already been done, for libtool
> 1.5.
Not true. There were some patches backported even before now,
I was doing some of the work under the expectation that we can
see a
> Yes, you already said that. The stuff above is about the libtool 1.4
> _branch_, while the libtool-darwin patch is in the mainstream development tree.
Right, and I have not yet seen anything that said there will be a
libtool 1.4.3 release, only that there will be a libtool release in
general, s
Akim Demaille <[EMAIL PROTECTED]> writes:
> If people consider we deliberatedly broken bugward compatibility, then
> fine, you're free to be wrong. It's not what happened (and I can tell
> you that a lot of code would not have been written if that was our
> intention), but I don't care what peop
After seeing what has happened with Autoconf, and given the current
state of libtool, I recommend that the focus of libtool development be
to produce a libtool 1.5 as soon as possible and not spend time
producing a libtool 1.4.3.
Time spent on libtool 1.4.3 is time spent doing work which must
eit
> The community are the maintainers, therefore a maintainer has spoken for
> a minor version increment, rather than a patch release increment.
Do you mean a minor version increment starting from branch-1_4 or from HEAD?
Paolo
___
Libtool mailing li
>
> On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote:
>
> >> so diff would be just in the last part around `-install_name
> >> $parth/$soname`
> >>
> >
> > Good to know. Is there an anonymous CVS access? If yes, where and how?
> > Then I could give you a diff against this branch
| > Sascha> and contains a dependency-ignorant cache system.
| >
| > What do you mean?
|
| Each of PHP's bundled extensions has a config.m4 which can be
| maintained separately. Autoconf 2.50 and later insert stale
| code into configure, when such a config.m4 file changes.
You want
Hello there
Did you know that you can program smart
cards with files from the internet and open lots of pay per view chanells
for
your televisual pleasure.
Take a look at http://MagicFun.da.ru for the latest hex
files.
Many thanks Jay.
[Cc trimmed]
> That's because it does provide a better service too :( I have timed a
> lot of the code, and I can tell that we're hitting a M4 limitation
> here. Hopefully future version of GNU M4 will help.
In the mean time, we are happy to pursue our use of
autoconf 2.13.
> Sasc
Paolo Bonzini wrote:
>>Wouldn't it be better to get libtool 1.5 out the door? The resources
>>required to achieve a releasable product are similar and CVS libtool
>>already contains most of the fixes that would go into a 1.4.3.
>
>
> But it also contains more features. Releasing 1.5 should
On 9 Oct 2002, Akim Demaille wrote:
> Whatever your opinion is, this debate is anyway a total loss of time
> for all of us (except for having the opportunity of reading the few
> usual good laughs from TEDdy Bear, the great clown of our mailing
> lists) since Autoconf will not be more 2.13 compat
> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> Ok, So a 1.4.3 version is desired, that's established. The
Robert> million-dollar question is: Does current branch-1-4 Libtool do
Robert> the trick?
Robert> If so, then a roll out could be done within the week.
I would like to
> "Russ" == Russ Allbery <[EMAIL PROTECTED]> writes:
Great thread people! I'm happy to see you're alive :)
Russ> There were a variety of reasons for breaking backward
Russ> compatibility, like choosing to clean up quoting, but that's a
Russ> justification for doing it, not an argument that
> "Sascha" == Sascha Schumann <[EMAIL PROTECTED]> writes:
Sascha> We use it for the PHP project (>80k lines configure script),
Sascha> because 2.5x is 5 to 6 times slower
That's because it does provide a better service too :( I have timed a
lot of the code, and I can tell that we're hittin
Thomas Dickey <[EMAIL PROTECTED]> writes:
|> On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
|> > In my experience almost all problems that occur while moving to autoconf
|> > 2.5x are outright bugs in the configure.in/aclocal.m4 scripts.
|>
|> We've already discussed this before
On Wed, Oct 09, 2002 at 01:15:07PM +0200, Andreas Schwab wrote:
> Thomas Dickey <[EMAIL PROTECTED]> writes:
>
> |> On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
> |> > In my experience almost all problems that occur while moving to autoconf
> |> > 2.5x are outright bugs in the c
On Wednesday, October 9, 2002, at 01:20 AM, Christoph Egger wrote:
>> so diff would be just in the last part around `-install_name
>> $parth/$soname`
>>
>
> Good to know. Is there an anonymous CVS access? If yes, where and how?
> Then I could give you a diff against this branch, if merging makes
On Wed, Oct 09, 2002 at 12:09:09PM +0200, Andreas Schwab wrote:
> In my experience almost all problems that occur while moving to autoconf
> 2.5x are outright bugs in the configure.in/aclocal.m4 scripts.
We've already discussed this before, and I decided not to rely upon your opinion
--
Thomas
"Thomas E. Dickey" <[EMAIL PROTECTED]> writes:
|> On Tue, 8 Oct 2002, Lars Hecking wrote:
|>
|> > Bob Friesenhahn writes:
|> > > On 8 Oct 2002, Akim Demaille wrote:
|> > > >
|> > > > There is one big question which must be answered first: will it have
|> > > > to be Autoconf 2.13 compatible?
|>
40 matches
Mail list logo
