freedce/win32 - making progress.

[Luke Kenneth Casson Leighton]

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 at 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>
--