libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support for C++ under Win32


From: Gary V . Vaughan
Subject: Re: Support for C++ under Win32
Date: Tue, 3 Apr 2001 22:32:12 +0100

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: address@hidden
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       address@hidden
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc



reply via email to

[Prev in Thread] Current Thread [Next in Thread]