On Thu, 2002-10-10 at 11:11, Boehne, Robert wrote:
> A similar case is the use of $ORIGIN/ in a hardcoded
> library path. Not many OS's support it, and anyone
> who depends on it would limit the possible supported
> platform list down to only those that do.
Ahh, I see what you're saying. No, t
Benjamin,
My point is that it would encourage developers to
write softwre that would ONLY compile on Darwin.
A similar case is the use of $ORIGIN/ in a hardcoded
library path. Not many OS's support it, and anyone
who depends on it would limit the possible supported
platform list down to only th
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+
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, 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
> > 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
> 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
>
> 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
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
>
>
> Bruce Korb wrote:
> > Christoph Egger wrote:
> >
> >
> >>Ok, here we come: I just did 2)
> >>The fix is replacing this line
> >>
> >>archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> >>echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> >>$deplibs$linker_flags -i
Bruce Korb wrote:
> Christoph Egger wrote:
>
>
>>Ok, here we come: I just did 2)
>>The fix is replacing this line
>>
>>archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
>>echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
>>$deplibs$linker_flags -install_name $rpath/$sona
> While we're on the subject of darwin and libtool, we've been needing to
> make changes to libtool to make KDE compile on darwin that haven't been
> discussed in this thread.
>
> Darwin's GCC has a number of very weird states it can get into during
> the linking stage because of it's crappy ld (
While we're on the subject of darwin and libtool, we've been needing to
make changes to libtool to make KDE compile on darwin that haven't been
discussed in this thread.
Darwin's GCC has a number of very weird states it can get into during
the linking stage because of it's crappy ld (grin), and I
> In regard to: Re: libtool 1.4.2 on Darwin, Christoph Egger said (at
> 11:26pm...:
>
> >Ok, here we come: I just did 2)
> >The fix is replacing this line
> >
> >archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
>
> Christoph Egger wrote:
>
> > Ok, here we come: I just did 2)
> > The fix is replacing this line
> >
> > archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> > echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> > $deplibs$linker_flags -install_name $rpath/$soname $verstri
In regard to: Re: libtool 1.4.2 on Darwin, Christoph Egger said (at 11:26pm...:
>Ok, here we come: I just did 2)
>The fix is replacing this line
>
>archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
>echo -dynamiclib) $allow_undefined_flag -
Christoph Egger wrote:
> Ok, here we come: I just did 2)
> The fix is replacing this line
>
> archive_cmds='$nonopt $(test "x$module" = xyes && echo -bundle ||
> echo -dynamiclib) $allow_undefined_flag -o $lib $libobjs
> $deplibs$linker_flags -install_name $rpath/$soname $verstring'
>
> by this
> Christoph Egger wrote:
> >
> > All what I want are three things:
> >
> > 1) That my above fix becomes part of one of the next libtool releases
> > 2) That libtool calls gcc with the right params, so that gcc doesn't
> break
> > the compiling process with 'gcc: -install_name only allowed with
>
Christoph Egger wrote:
>
> All what I want are three things:
>
> 1) That my above fix becomes part of one of the next libtool releases
> 2) That libtool calls gcc with the right params, so that gcc doesn't break
> the compiling process with 'gcc: -install_name only allowed with
> -dynamiclib'
> >>Christoph Egger wrote:
> >>
> >>I am running Darwin 6.1. libtool 1.4.2, autoconf 2.52 and automake
> >>1.6.1 are shipped with it.
> >>
> >>The application I write loads dynamic libs at runtime or at least it
> >>should.
> >>But Darwin says, the dynamic lib are not of the right type of object
>
> Isn't that the old zsh qouting bug? Well, people still refuse to give us
> an 1.4.3 anysoon, so may be you want to expand your configure scripts
> with:
>
http://ac-archive.sf.net/Installed_Packages/patch_libtool_on_darwin_zsh_overquoting.html
zsh? Is that yet another shell?
I use the bash shel
Isn't that the old zsh qouting bug? Well, people still refuse to give us
an 1.4.3 anysoon, so may be you want to expand your configure scripts with:
http://ac-archive.sf.net/Installed_Packages/patch_libtool_on_darwin_zsh_overquoting.html
Christoph Egger wrote:
> Usually I don't reply myself, but
Usually I don't reply myself, but I have some news related to my problem:
> > Hi!
> >
> > I am running Darwin 6.1. libtool 1.4.2, autoconf 2.52 and automake 1.6.1
> are
> > shipped with it.
> >
> > The application I write loads dynamic libs at runtime or at least it
> should.
> > But Darwin say
Sorry for resending this mail, but I forgot two things:
1. An appropriate subject
2. To mention, that I am NOT subscribed on this list. So please CC me all
mails belonging to this thread, please.
> Hi!
>
> I am running Darwin 6.1. libtool 1.4.2, autoconf 2.52 and automake 1.6.1
are
> shipped
25 matches
Mail list logo
