hello peter, thank you v. much for the advice. yes i tried -no-undefined, it got a little further but no banana :)
will look at that patch, let you know if it helps
On Wed, Sep 21, 2005 at 01:44:12PM +0200, Peter Ekberg wrote:
Hi!
- Luke Kenneth Casson Leighton writes:
okay, i'm getting somewhere, and there's a key part that i would appreciate some advice about: if there is anyone who knows how to do cross-compiling of dlls using libtool, mingw32 (in automake Makefile.am's) where the dlls need to link against _other_ libraries, i would love to hear from you.
if you know of a better place to ask questions such as these, i would also appreciate some advice on where i should ask them.
Perhaps libtool@gnu.org, but please be more detailed in what you're trying to do and what you want to happen.
[please respond cc direct because although i am subscribed to the wine-devel list i have "receive postings" switched off because i haven't sufficient time any more to sort or delete hundreds of messages per day like i used to have. ]
there are about eight libraries containing a function rpc__module_init_func() and these need to be LoadLibrary'd and GetProcAddress'd and called...
... but in endeavouring to create dlls, i am getting mad warnings from libtool about a) static libraries containing unresolved functions therefore libtool says it _could_ link against the library you requested, but only if you made a dynamic version and b) unresolved symbols for functions in other libraries, and it's all a bit of a vicious circle and i'd rather not bash my head against a brick wall for days on this.
You could try the first patch in this post: http://lists.gnu.org/archive/html/libtool/2005-09/msg00063.html
It just might help...
It could also be that it's as simple as saying -no-undefined to libtool, that option is needed on windows.
But as always it's hard to tell without all the gory details.
if this issue cannot be resolved then there are a number of nasty options remaining:
- statically link binaries against the libraries, with hard-coded
module init functions (which is what i'm doing now and i link against libnaf_ip.la, libcom.la, libprot_ncacn.la, libprot_ncadg.la, the list goes on and you have to do that for EVERY client AND server program)
- abandon automake, work out how to manually create dlls. yes i know
about .def files but libtool appears unconvinced.
neither of these two is attractive options.
anyway: what i have working so far can be found at the freedce-devel sf.net mailing list archives, and as of today, rpcd (the endpoint
mapper
on port 135) works.
and also when i add a NamedPipes transport (ncacn_np) it will be on \PIPE\epmapper, too. that'll be a fun job. no, really!
tomorrow's job is to link the echo_server and test that, and if that works, try the echo_client too.
if those work, then the free software community will have its own DCE/RPC reference implementation running on win32.
much damn good may it do, i am sure.
l.
p.s. thank goodness for pthreads-win32.
Cheers, Peter