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: > > > > 1) 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) > > > > 2) 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 -- -- <a href="http://lkcl.net">http://lkcl.net</a> --