public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* dllimport question
@ 2003-01-28 17:36 Paul Kienzle
  2003-01-29  1:35 ` [Mingw-users] " Danny Smith
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Kienzle @ 2003-01-28 17:36 UTC (permalink / raw)
  To: gcc-help

Hi!  

I'm using g++ under windows to create some separately
loadable modules for GNU Octave.  As it stands, libstdc++
is linked statically and each module huge.  To reduce the
dll size, I've been trying to create a dll version of
libstdc++.

Using dlltool, this isn't too hard, though I do have to
use the following in my source: 
  #include <iostream>
  namespace std { 
	__declspec(dllimport) ostream cout; 
  } ;
The resulting program size (25787) is considerably smaller 
than that from linking directly to libstdc++.a (448537), 
even after stripping (210944).

I've included hello.cc and Makefile below.
Use "make hello" to test.  You may have to change the
STDCXX variable to point to the appropriate libstdc++.a

The problem comes when I use possibly different 
__declspec(dllimport) commands in separately compiled 
modules.  In this case I get the link error:
  world.o(.bss+0x0):world.cc: multiple definition of `D'
  hello.o(.bss+0x):hello.cc: first defined here
This error does not occur using __declspec(dllimport) in
C source.  nm shows the _D symbol marked with 'C' when
compiled with gcc, and 'B' when compiled with g++.

Use "make world" to generate the error.

I get the same error on two compilers
   mingw:  gcc version 3.2 (mingw special 20020817-1)
   cygwin: gcc version 3.2 20020927 (prerelease)
I even get the error when not doing any tricks with
libstdc++, but just have __declspec(dllimport) statements
in different .o files which I am linking together.

Any idea what I am doing wrong?

Is there a better way to avoid linking libstdc++ into
all separately loaded modules?

Thanks in advance,

Paul Kienzle
pkienzle@nist.gov

PS, please CC any responses to me as I am not subscribed to
the list.

--- Makefile ---

STDCXX=/usr/lib/libstdc++.a
#STDCXX=/mingw/lib/libstdc++.a
%.o: %.cc ; g++ -c $< -o $@ -DSTDCXX_DLL

hello: hello.o libstdc++.dll
	gcc -o $@ $< -Wl,--enable-auto-import -L. -lstdc++.dll

world: hello.o world.o libstdc++.dll
	gcc -o $@ hello.o world.o -Wl,--enable-auto-import -L. -lstdc++.dll

libstdc++.dll: ${STDCXX}
	dlltool --export-all --output-exp $@.exp --dllname $@ --output-lib $@.a $<
	gcc -shared $@.exp $< -o $@
	rm $@.exp

clean:
	rm -f *.o *.a *.dll *.exe

--- hello.cc ---

#include <iostream>

#if defined(STDCXX_DLL)
namespace std { __declspec(dllimport) ostream cout; } ;
#endif

int main(int argc, char *argv[])
{
   std::cout << "Hello, world!" << std::endl;
   return 0;
}

--- world.cc ---

#include <iostream>
#if defined(STDCXX_DLL)
namespace std { __declspec(dllimport) istream cin; } ;
#endif
int world(void)
{
  int x;
  std::cin >> x;
  return x;
}

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Mingw-users] dllimport question
  2003-01-28 17:36 dllimport question Paul Kienzle
@ 2003-01-29  1:35 ` Danny Smith
  2003-01-29  7:58   ` Paul Kienzle
  0 siblings, 1 reply; 3+ messages in thread
From: Danny Smith @ 2003-01-29  1:35 UTC (permalink / raw)
  To: Paul Kienzle, gcc-help


----- Original Message -----
From: "Paul Kienzle" <pkienzle@jazz.ncnr.nist.gov>
To: <gcc-help@gcc.gnu.org>
Sent: Tuesday, 28 January 2003 17:36
Subject: [Mingw-users] dllimport question


> Hi!
>
> I'm using g++ under windows to create some separately
> loadable modules for GNU Octave.  As it stands, libstdc++
> is linked statically and each module huge.  To reduce the
> dll size, I've been trying to create a dll version of
> libstdc++.
>
> Using dlltool, this isn't too hard, though I do have to
> use the following in my source:
>   #include <iostream>
>   namespace std {
> __declspec(dllimport) ostream cout;
>   } ;


Change this to

extern __declspec(dllimport) ostream cout;
^^^^^^
cout is an object.

With more recent GCC , the extern is supplied implicitly when dllimport
is used in declaration. With 3.2.0 it is not.

Danny

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Mingw-users] dllimport question
  2003-01-29  1:35 ` [Mingw-users] " Danny Smith
@ 2003-01-29  7:58   ` Paul Kienzle
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Kienzle @ 2003-01-29  7:58 UTC (permalink / raw)
  To: Danny Smith; +Cc: gcc-help

On Wed, Jan 29, 2003 at 01:31:24AM +0000, Danny Smith wrote:
> 
> > I'm using g++ under windows to create some separately
> > loadable modules for GNU Octave.  As it stands, libstdc++
> > is linked statically and each module huge.  To reduce the
> > dll size, I've been trying to create a dll version of
> > libstdc++.
> >
> > Using dlltool, this isn't too hard, though I do have to
> > use the following in my source:
> >   #include <iostream>
> >   namespace std {
> > __declspec(dllimport) ostream cout;
> >   } ;
> 
> 
> Change this to
> 
> extern __declspec(dllimport) ostream cout;
> ^^^^^^
> cout is an object.
> 
> With more recent GCC , the extern is supplied implicitly when dllimport
> is used in declaration. With 3.2.0 it is not.

Thanks!  Works like a charm.  Now all I have to do is figure out what to
do with the following variables:

	vtable for __cxxabiv1::__si_class_type_info
	vtable for __cxxabiv1::__class_type_info
	std::basic_string<char, std::char_traits<char>, std::allocator<char>>::_S_empty_rep_storage
	std::basic_string<...>::_Rep::_S_terminal
	std::basic_string<...>::_Rep::_S_max_size

Any suggestions?

Paul Kienzle
pkienzle@nist.gov	

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-01-29  7:58 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-28 17:36 dllimport question Paul Kienzle
2003-01-29  1:35 ` [Mingw-users] " Danny Smith
2003-01-29  7:58   ` Paul Kienzle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).