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
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,
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 you
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
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
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 cvs
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.
, 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 says, the dynamic lib are not of the right type of object
file
.
Christoph Egger wrote:
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
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
file.
Having a closer
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'
3)
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'
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 -o $lib $libobjs
$deplibs$linker_flags
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
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 -o $lib $libobjs
$deplibs$linker_flags
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
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
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/$soname $verstring'
by
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/$soname
19 matches
Mail list logo
