On Monday 25 November 2002 2:43 pm, Max Horn wrote:
> An alternate solution might be to change the kbackgammon exectuable
> to load the kbackgammon.so, too, instead of linking against it. Or is
> there anything else that needs to link against these loadable modules?
Why? What benefit is there in
An alternate solution might be to change the kbackgammon exectuable
to load the kbackgammon.so, too, instead of linking against it. Or is
there anything else that needs to link against these loadable modules?
Max
--
---
Max Horn
Software Developer
em
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
On Monday 25 November 2002 10:47 am, David wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > Feel free to take the patches from NetBSD pkgsrc and makes noises with
> > the KDE people. http://www.netbsd.org/Documentation/software/packages.html
> >
> No need to make noise with
Ooops, so I did not read the patch too closely - thanks for
the clarification. IOW, there are now two dummy binaries,
one is the system executable, the other is the dlopen-able
module, and both depend on a single system lib*.la - cute!
just to check back with the darwin'ers: a dlopen().so can
link
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
>Feel free to take the patches from NetBSD pkgsrc and makes noises with
the KDE
people. http://www.netbsd.org/Documentation/software/packages.html
No need to make noise with the KDE people, I am reading this list
*grins* If you have a patch a
On Monday 25 November 2002 10:04 am, Guido Draheim wrote:
> It's the correct solution AFAICS - from the same sources two
> libtool libraries are built - one is a system library that
> gets linked to the system binary. And the module libtool
> archive is separate from that. Both .la will be able to
It's the correct solution AFAICS - from the same sources two
libtool libraries are built - one is a system library that
gets linked to the system binary. And the module libtool
archive is separate from that. Both .la will be able to pick
up the same .lo being compiled along, so it is nothing more
t
On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote:
> 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.
This was talked about some time ago by Michael Matz and myself.
> To get aro
is this discussion informed by libtool preopen facilities?
thi
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Benjamin Reed wrote:
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
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
Benjamin Reed wrote:
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
Benjamin Reed wrote:
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 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: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
Benjamin Reed wrote:
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=lin
Guido Draheim wrote:
Benjamin Reed wrote:
[...]
---(snip!)---
kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module
-avoid-version
kbackgammon_LDADD = kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
---(snip!)---
...this is a no-no, kbackgammon is trying
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
Benjamin Reed wrote:
[...]
---(snip!)---
kbackgammon_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module
-avoid-version
kbackgammon_LDADD = kbackgammon.la $(LIB_KDEGAMES) $(LIB_KSYCOCA)
kbackgammon_SOURCES = dummy.cpp
---(snip!)---
...this is a no-no, kbackgammon is trying to link against a bund
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
21 matches
Mail list logo
