On Tuesday 03 April 2001 8:32 pm, Kevin Atkinson wrote:
> On Sun, 1 Apr 2001, Gary V. Vaughan wrote:
> > On Friday 30 March 2001 3:54 am, Kevin Atkinson wrote:
> > > I was wondering what the status is for supporting C++ on Win32 in the
> > > multi-language branch of libtool.
> >
> > The g++ support for win32 should not be any worse than for other libtool
> > supported platforms.
>
> Are you referring to the MAIN branch of libtool or the multi-library
> branch? I am talking about the multi-language branch here. In
> particular the multi-language branch does not seam to support creating a
> dll for g++ under Cygwin.
Trunk releases. I have fastidiously installed only automake-1.4 and
autoconf-2.13, and used only HEAD releases of libtool to make sure the
migration path for users of libtool-1.4 will be nice.
> I currently use the multi-library branch so the building C++ libraries
> works correctly without having to worry about linking in the C++ standard
> library or global constructors being called.
I'm already out of my depth here... C++ is not really in my area of
expertise.
> > > I also need ltdl to work properly under
> > > Win32 so that I can dynamically load a dll at run time so that Pspell
> > > will work under Win32.
> >
> > Apart from brokenness in the DLL design, this also more or less works.
> > It is easy if you build your project from scratch knowing you want DLL
> > builds, but becomes difficult quite quickly if the package author assumed
> > ELF type libs.
>
> By this do you mean linking with undefined symbols?
Among others.... of the top of my head:
And lack of back-linking --DLL code can't call functions in the executable
that loaded it.
And variable symbol exports -- the compiler generates different code for
importing a variable from a DLL than from a static lib.
And splitting the code for a DLL across 2 files -- import lib and DLL.
And the DLL search algorithm -- no difference (apart from searching the
current directory first) between the executable search path nd the library
search path.
> My code uses libltdl
> to load a single symbol from the module. This symbol is a function with
> C linkage which will return a new Manager class. From that point on
> inheritance is used and I never try to access any other symbols located in
> that module directly. Is this safe?
It sounds okay to me. But then I am hardly an authority on C++ matters =(O|
> The relevant code:
>
> int s = lt_dlinit();
> assert(s == 0);
> PspellString libname;
> libname = LIBDIR "/libpspell_";
> libname += name;
> libname += ".la";
> lt_dlhandle h = lt_dlopen (libname.c_str());
> if (h == 0)
> return (new PspellCanHaveErrorImpl())
> ->set_error(cant_load_module, name.c_str());
> lt_ptr_t fun = lt_dlsym (h, "new_pspell_manager_class");
> assert (fun != 0);
> PspellCanHaveError * m = (*(NewPspellManagerClass)(fun))(config, h);
> assert (m != 0);
> if (m->error_number() != 0)
> free_lt_handle(h);
> return m;
>
> This is located in the Pspell program which you can find at
> http://pspell.sourceforge.net.
Sorry I couldn't be more helpful.
Cheers,
Gary.
--
___ _ ___ __ _ mailto: [EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
