g this and
still be a nice neighbor? =)
TIA,
Benjamin Reed
[EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
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
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
> 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 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
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+
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
One of the problems we're running into getting KDE working on Darwin is
libtool's concept of a "module", and how it's mapped onto Darwin's
linker behavior.
On Darwin, unlike most other unixen (as far as I'm aware), loadable
modules and dynamic shared libraries are 2 distinctly different
entiti
On Sunday, November 24, 2002, at 04:54 PM, Guido Draheim wrote:
The only hint that I can give has the form of a question: Did you try
kbackgammon_LDADD = -static kbackgammon.la $(LIB_KDEGAMES)
$(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
$ ./libtool --help --mode=link | grep static
-all-s
On Sunday, November 24, 2002, at 05:13 PM, Guido Draheim wrote:
I mean, that should also be seen on other platforms than darwin, right?
Or am I mistaken here? (I wouldn't count myself to know large parts of
libtool indepth, well, then again, who still does ;-) ...)
Well, on pretty much every ot
On Sunday, November 24, 2002, at 05:17 PM, Guido Draheim wrote:
That's actually the difference between "-all-static" and "-static"
IIRC.
The "-static" should only link its .la's as static, and non-la's
dynamic.
But perhaps I am mistaken too, that's why I did ask if you did try
somewhen.
Well,
On Sunday, November 24, 2002, at 05:44 PM, Guido Draheim wrote:
You mean they are listed as ".la" on the link-line?
To stick with the example, there is a
LIB_KDEGAMES = libkdegames.la
in your makefiles? aargh, kde maniacs at work
No, it would be, libfoo_la_LIBADD =
$(top_builddir)/kdec
That's great news. I cannot, however, promise to have these available
anytime
soon. I would appreciate help. Anyone?
I can certainly help out with this. While waiting for more input on
this thread, I actually ended up coming up with the same solution last
night. I woke up this morning to find
So the discussion came up on the fink irc channel again about libtool
and namespaces. I recall being rejected in wanting to add support for
linker namespaces in libtool in the thread following this post:
http://www.mail-archive.com/libtool@gnu.org/msg03042.html
...but looking at the archives
On Sunday, February 2, 2003, at 11:23 AM, Benjamin Reed wrote:
He suggested changing it to "-multiply_defined suppress prebind",
which seems to be the solution, if libtool doesn't want to support
specifying the namespace on the libtool command-line.
This would make libtool de
Well, I think that building thing two level namespace ought to be the
libtool default also, flat_namespace is needed for some things but
causes problems for many others, how about trying both by default?
cc -multiply_defined suppress -prebind blah || cc -flat_namespace
-undefined suppress blah
On Tuesday, February 4, 2003, at 09:46 PM, Albert Chin wrote:
I think we should support the two-level namespace, even if it is
OSX-specific. I look at libtool more as a way to easily build shared
libraries across multiple platforms.
Think about AIX. An AIX shared library (non-brtl) can contain *
well, now that Peter's patches are in libtool, it appears to be working
again on MacOSX -- however, for some reason it seems to be trying to
relink some libraries (not sure why, library paths are coded into the
lib already, there's really no reason to ever relink on MacOSX).
I'm trying to updat
On Tuesday, February 25, 2003, at 08:12 PM, Benjamin Reed wrote:
well, now that Peter's patches are in libtool, it appears to be
working again on MacOSX -- however, for some reason it seems to be
trying to relink some libraries (not sure why, library paths are coded
into the lib al
On Tuesday, February 25, 2003, at 10:30 PM, Peter O'Gorman wrote:
Ben,
I have a patch to disable relinking, for some reason on current
libtool,
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
This is wrong, and makes libtool think relinking is required, set it
to no.
I am not sure if you also need to set
Peter O'Gorman wrote:
Hi,
While we need to link all deplibs (actually link against them, not just
-L to the dir) on darwin, we only need to do so for shared libraries.
This patch fixes that.
Also, I had left a couple of printf's in the ltdl code for dyld, and
incorrectly returned a 1 in dlcose
(which libtool normally does, but there are
cases in which it won't).
For the future portability, I implore that you go with what Bob
suggested. :)
- --
Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
A computer scientist is someone who, when told to 'Go to Hell',
I'm not sure how to go about fixing this, but I'm running into an issue
in trying to build KDE from CVS against Qt/Mac 3.2.0. The problem is,
Qt 3.2 now creates a .la file, which contains -framework lines like so:
---(snip!)---
# libqt-mt.la - a libtool library file
# Generated by qmake/libtool
On Aug 29, 2003, at 12:55 AM, Daniel Reed wrote:
To produce only .la and .so files, you can pass -module -avoid-version
to
libtool. In Automake, you can do this by using something similar to:
pkglib_LTLIBRARIES = mymod.la
mymod_la_SOURCES = mymod.c
mymod_la_LDFLAGS = -module -avoid-version
This
Sushil Kambampati wrote:
Hi,
Can someone please tell me what should I do to suppress the
-single_module flag when linking with libtool in Mac OS X 10.3?
Thanks in advance.
See my post to teh unix-porting list; your gcc is broken...
--
Benjamin Reed a.k.a. Ranger Rick -- http
Since on darwin shrext is dependent on whether the library is a module
or not, shrext is set to a test that gets eval'd later.
It appears that sometime in the last month or two, changes have made it
so that shrext is evaluated *before* the command-line arguments are
parsed, and thus shrext is a
On a closer inspection, it appears that the problem is with kde's
libtool handling. since they put libtool.m4 as part of their
acinclude.m4, I think the quoting is getting removed when it's getting
run through configure.
I'm having trouble figuring out where the fault lies. I see that shrext
I'm trying to build aRts using the 1.5 branch (as of a day or two ago)
on Mac OS X, and when I build it gives this error:
---(snip!)---
10-0-4-104:/sw/build/arts-1.3.0-1/arts-1.3.0 root# make -j1
cd . && /bin/sh ./config.status config.h
config.status: creating config.h
config.status: config.h is u
The error occurs when libtool is called with a subdirectory when
creating libraries and binaries linked against those libraries and a
wrapper script is created.
Attached is a script that reproduces the error, and the output is as
follows:
---(snip!)---
10-0-4-38:~/tmp ranger$ ./libtool-1.5.14-dar
29 matches
Mail list logo
