If -lwinmm is the only problem, or the typical problem, I know the solution.
Either mingw will provide Windows libraries such as libwinmm.a or
libdsound.a (they certainly are a part of Dev-C++'s distribution of mingw,
and I use them in CsoundVST) or we can make GNU import libraries for them
using dlltool. I thought you meant you weren't sure how to get libtool to
link any kind of dll.

It would be great if you could switch to FLTK, as that would reduce Csound's
external dependencies.

============================================
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 9:13 AM
Subject: [CSOUND-DEV:3762] Re: Csound GNU build system lessons learned


> "Michael Gogins"  writes:
>
> > I suggest the standard pattern as you say; elaborating this, I
> > suggest the structure outlined below.
>
> Very nice.
>
> > One major feature of this structure is that the csound/src/csound
> > directory contains all the original Csound sources and does NOT
> > contain any projects with external dependencies (no third party
> > libraries such as FLTK or the VST SDK).
>
> I totally agree.
>
> > csound
> >     src
> >         csound // traditional csound slightly reorganized, no external
dependencies
>
> In order to make csound-config work properly, csound/src/csound should
> contain both csound-config.in and the headers that are installed,
> i.e., the ones installed into the directory /usr/include/csound by
> default.  With this organization, clients of the csound API include
> , and the use of the --inplace option of
> csound-config will do the right thing.
>
> > If we can't get libtool to build Windows DLLs, then we should drop
> > libtool and just use custom rules in the Makefile.am's.
>
> Correct, but remember, I'm the only who has been looking at this
> problem.  I've never claimed to be a Windows expert.  Currently, the
> DLL generation problem seems to be that libtool cannot handle -lwinmm,
> which is needed for MIDI support.  There is something funky about
> Cygwin's version of winmm.  I am confident I could generate a DLL if I
> didn't have to link with winmm.
>
> > As for FLTK and tabbed panels, CsoundVST has tabbed panels, so I'm
> > not sure what you're talking about.
>
> I guess I have to read the FLTK documentation yet again.  The downside
> of wxWindows is it is a heavy weight solution, so if I can, and it
> doesn't take too much effort, I'd like switch to FLTK.
>
> John
>

"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