If a Windows DLL contains export records (created by __declspec(dllexport)
or, here, PUBLIC) then gcc can link directly with the DLL. You can tell if a
DLL contains export records if you run the Microsoft utility DUMPBIN.EXE
with the /EXPORTS option on the DLL. If you see any functions, there are
export records. If you don't see any functions, there still may be exported
functions but there are no export records; the functions can only be linked
using an import library (next item below).

If the Windows DLL does not contain export records, then the only way gcc or
any other compiler can link with the DLL is to link with an import library
(a static library) that has been created with a .def file. ccsound.exe would
need to link with the import library (libcsound.a).

ccsound.o (as opposed to .exe) does not need to know what symbols to import;
it only needs to know what symbols have been declared (usually in header
files). Only the linker and the operating system need to know what symbols
to import.

Pardon me if you already know this, as I suspect you do, and I'm missing the
point of your question...

============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================


----- Original Message ----- 
From: "John D. Ramsdell" 
To: "Csound Developers Discussion List" 
Sent: Monday, December 15, 2003 8:02 PM
Subject: [CSOUND-DEV:3775] Re: Csound GNU build system lessons learned


> "Michael Gogins"  writes:
>
> > I thought you meant you weren't sure how to get libtool to link any
> > kind of dll.
>
> I still think I don't understand it.  How does ccsound.o know what
> symbols to import?  Shouldn't csound/csound.h
> contain the following:
>
> #if defined _WIN32
> #  ifdef DLL_EXPORT
> #    define PUBLIC        __declspec(dllexport)
> #  else
> #    ifdef LIBCSOUND_DLL_IMPORT
> #      define PUBLIC      extern __declspec(dllimport)
> #    endif
> #  endif
> #  define LIBRARY_CALL
> #else
> #ifdef WIN32
> #define PUBLIC __declspec(dllexport)
> #define LIBRARY_CALL WINAPI
> #else
> #define PUBLIC
> #define LIBRARY_CALL
> #endif
> #endif
>
> I got this code from
>
> http://sources.redhat.com/autobook/autobook/autobook_255.html
>
> John
>

"Michael Gogins"  writes:

> Pardon me if you already know this, as I suspect you do, and I'm missing the
> point of your question...

Actually, I don't have a good question for you at this time, as I can
build a DLL that links with -lwinmm in a small test case, but doing
the "same thing" with Csound causes a linking failure.  Why the linker
can find the DLL in the test case, but not with Csound is still a
mystery, but I will continue to look for an explanation.

I did a lot of reading of info files on Cygwin.  My conclusion is that
the automake file in the directory used to build libcsound should
define BUILDING_LIBCSOUND when compiling files used to build
libcsound, and csound.h should start with:

#if defined HAVE_CONFIG_H && (defined _WIN32 || defined __CYGWIN__)
#  if !defined PIC
#    define PUBLIC
#  elif defined BUILDING_LIBCSOUND
#    define PUBLIC __declspec(dllexport)
#  else
#    define PUBLIC __declspec(dllimport)
#  endif
#  define LIBRARY_CALL WINAPI
#elif defined WIN32
#define PUBLIC __declspec(dllexport) 
#define LIBRARY_CALL WINAPI
#else
#define PUBLIC
#define LIBRARY_CALL
#endif

This way, PUBLIC has an empty definition when used with static
libraries or programs, is defined to be __declspec(dllexport) when
compiling libcsound as a DLL, and is defined to be
__declspec(dllimport) when using libcsound within another library
being compiled as a DLL.

By the way, what is LIBRARY_CALL used for?  I don't see it in any
source code.

John

[ramsdell@couch csound]$ sfcvs csound diff -u
ramsdell@cvs.csound.sourceforge.net's password:
Index: csound/Makefile.am
===================================================================
RCS file: /cvsroot/csound/csound/csound/Makefile.am,v
retrieving revision 1.13
diff -u -r1.13 Makefile.am
--- csound/Makefile.am	15 Dec 2003 11:08:49 -0000	1.13
+++ csound/Makefile.am	17 Dec 2003 15:34:08 -0000
@@ -87,7 +87,9 @@
 winFLTK.c FL_graph.cpp widgets.cpp wincwin.c winBe.c winSGI.c winwat.c	\
 winbor.c windin.h cwin.cpp cwin.h
 
-libcsound_la_CFLAGS = -DXMGDIR=\"$(pkgdatadir)\" -DUSE_CSOUND_YIELD
+libcsound_la_CFLAGS = -DXMGDIR=\"$(pkgdatadir)\" -DUSE_CSOUND_YIELD	\
+-DBUILDING_LIBCSOUND
+libcsound_la_CXXFLAGS = $(AM_CXXFLAGS) -DBUILDING_LIBCSOUND
 libcsound_la_LDFLAGS = -version-info 0:0:0 -no-undefined
 libcsound_la_LIBADD = $(AUDOBJS) $(winobjs) $(AUDLIBS)
 libcsound_la_DEPENDENCIES = $(AUDOBJS) $(winobjs)
Index: csound/csound.h
===================================================================
RCS file: /cvsroot/csound/csound/csound/csound.h,v
retrieving revision 1.1
diff -u -r1.1 csound.h
--- csound/csound.h	29 Nov 2003 18:33:20 -0000	1.1
+++ csound/csound.h	17 Dec 2003 15:34:08 -0000
@@ -33,7 +33,16 @@
         /*
         * Platform-dependent definitions and declarations.
         */
-#ifdef WIN32
+#if defined HAVE_CONFIG_H && (defined _WIN32 || defined __CYGWIN__)
+#  if !defined PIC
+#    define PUBLIC
+#  elif defined BUILDING_LIBCSOUND
+#    define PUBLIC __declspec(dllexport)
+#  else
+#    define PUBLIC __declspec(dllimport)
+#  endif
+#  define LIBRARY_CALL WINAPI
+#elif defined WIN32
 #define PUBLIC __declspec(dllexport) 
 #define LIBRARY_CALL WINAPI
 #else

"Michael Gogins"  writes:

> You can tell if a DLL contains export records if you run the
> Microsoft utility DUMPBIN.EXE with the /EXPORTS option on the DLL.

I searched my Windows 2000 installation for dumpbin, but no files
matching that name were found.  May be one only gets this utility when
a Microsoft IDE is installed.

> If the Windows DLL does not contain export records...

The reason I strongly suspect winmm has export records is a small test
case I wrote links with a little DLL I generated with no linking
problems.

> Pardon me if you already know this, as I suspect you do, and I'm
> missing the point of your question...

Actually, this is the first I've heard of dumpbin.exe, so I'm glad you
noted it.

John