gcc is the same up to a point. The gcc library includes the runtime library
proper, which is pretty much the same on all platforms, and the system
calls, which are not necessarily the same. For example, Cygwin has gcc, but
the Cygwin gcc has import libraries for all the Windows libraries,
including the multimedia library and the COM support libraries.

autoconf probes for headers, libraries, and such by searching the file
system, and then actually attempting to compile and link test programs;
i.e. to see if dlopen is available, autoconf will write a C program that
calls dlopen, and see if the test program compiles. If it compiles the
header is there; if it links the library is there.

The alternatives to autotools are boost jam (oriented towards C++) and
CMake. I have not evaluated CMake. I looked briefly at boost and it looked
good, but it was obviously dealing with exactly the same set of problems as
autotools. 

Autotools are by far the most widely used system of this kind.

Original Message:
-----------------
From: Gabriel Maldonado g.maldonado@inwind.it
Date: Tue, 24 Feb 2004 19:02:11 +0100
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:4141] Re: autoreconf -i -f


A real headache!! So the various unixes are much more different than I 
though... thanks for clarify this...

Is the gcc distribution of compatible between unixes, at least in a 
fixed version? More precisely, is its runtime library API identical? How 
  is it possible to exactly know  what are the runtime libraries 
installed on a particular UNIX? Are these tools able to recognize it 
automatically? What are the alternatives on using autoconf/automake/libtool?

Gab

Michael Gogins wrote:
> Each brand of Unix and Linux has different runtime libraries with a
> different set of functions, in different lib and header directories with
> different filenames, and sometimes different compilers with different
flags.
> autoconf figures this stuff out and automatically writes a header file to
> #ifdef macros to help you write code for all possibilities. automake uses
> that header file and other info to write makefiles that know where and
what
> the libs, headers, and flags are. It also works (mostly) on Windows with
> Cygwin or mingw, and perhaps it works to some extent on Mac OS X.
> 
> I've been through all contortions on this one for years, and that's why
I'm
> sticking with the pain of getting autotools to work, because I know they
can
> and other approaches are even more painful.
> 
> ============================================
> 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: "Gabriel Maldonado" 
> To: "Csound Developers Discussion List" 
> Sent: Tuesday, February 24, 2004 4:02 AM
> Subject: [CSOUND-DEV:4130] Re: autoreconf -i -f
> 
> 
> 
>>Are all these autotools stuff backward-compatible? What is the advantage
>>to use them instead of having a complete hand-written makefile? Isn't
>>the make language multi-platform? (excuse me for the ignorance, but I'm
>>only using MSVC and dev-cpp, both generating a makefile automatically
>>and in a very easy way).
>>
>>gab
>>
>>Anthony Kozar wrote:
>>
>>>Sorry, I guess that I had the impression that anyone trying to install
>>>Csound from source would have to go through the same steps that were
>>
> being
> 
>>>discussed on the list.  If running the configure script does not require
>>>having autotools, then I guess that we are in good shape.
>>>
>>>Thanks for the info Steven :)
>>>
>>>Anthony Kozar
>>>anthony.kozar@utoledo.edu
>>>
>>>
>>>On 2/23/04 3:54 PM, steven yi etched in stone:
>>>
>>>
>>>
>>>>End user shouldn't need the autotools to compile as they would get a src
>>>>tarball that has all the auto-stuff predone, so will only need to do
>>>>"./configure; make".  For most end users, they probably shouldn't need
>>>>to compile either and just receive binaries (with installers, as Richard
>>>>Dobson mentioned).
>>>
>>>
>>>
>>
>>-- 
>>Gabriel Maldonado
>>http://csounds.com/maldonado
>>--
>>
> 
> 
> 


-- 
Gabriel Maldonado
http://csounds.com/maldonado
--


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

Hi all,

I noticed that libsndfile is built with GNU autotools.  Considering that 
the library is buildable on probably more platforms than we are 
currently targetting, it might be worth checking out it's configure.ac 
and Makefile.am for some ideas that would help get things sorted out on 
problematic platforms.  I'm assuming it's built for everyone here and 
that Erik de Castro Lopo has gotten things worked out over time as the 
library seems to work for everyone.

steven

Well, as an update to my earlier report, I tried to get libsndfile to
compile and link correctly again on Mac OS 9.  The config.h file for Mac was
a little out of date, as were the Mac headers that I was using.  Once I
updated to more recent headers, I only had to make two or three small
changes to the source and configuration header, and it built.

I linked the library with another open source program called amber, and it
seemed to be working, although I have only barely tested it.

The short of it is:  libsndfile is a go for Mac OS 9.

Anthony Kozar
anthony.kozar@utoledo.edu

On 2/24/04 2:20 PM, steven yi etched in stone:

> I noticed that libsndfile [...]
> I'm assuming it's built for everyone here and
> that Erik de Castro Lopo has gotten things worked out over time as the
> library seems to work for everyone.