I forget you are building on Linux! That is strictly a Windows option.

At any rate, main is properly defined in ccsound.c, so this is quite 
puzzling.

It's clear enough that the C runtime library is not finding main. The only 
thing I can come up with is that your machine has several versions of the C 
runtime library and you are trying to link with one that does not really 
work with the compiler.

----- Original Message ----- 
From: "steven yi" 
To: "Csound Developers Discussion List" 
Sent: Wednesday, December 22, 2004 3:27 PM
Subject: [CSOUND-DEV:5572] RE: Csound4 GBS not compiling


> No, should that be an option?  (I haven't seen that before).  Here's a 
> more exhaustive output:
>
> gcc -g -O2 -Wall -falign-loops=4 -falign-jumps=4 -ffast-math -fomit-frame-pointer 
>  -finline-functions -funroll-loops -O2 -g -pipe -march=i386 -mcpu=i686 -I/usr/X11R6/include 
>  -o csound ccsound.o 
>  ./.libs/libcsound.a -L/usr/X11R6/lib -lportaudio -lasound 
> /usr/lib/libfreetype.so -lz -lXrender -lfontconfig -lfltk -lXft -lXext -lX11 
>  -lsupc++ -lstdc++ -lpthread -ldl -lm
> /usr/lib/gcc/i386-redhat-linux/3.4.2/../../../crt1.o(.text+0x18): In 
> function `_start':
> : undefined reference to `main'
> collect2: ld returned 1 exit status
> make[2]: *** [csound] Error 1
> make[2]: Leaving directory `/home/steven/workspace/csound/csound'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/steven/workspace/csound/csound'
> make: *** [all-recursive] Error 1
>
> This also happens on my Fedora Core 2 system.
>
> steven
>
>
> gogins@pipeline.com wrote:
>
>>Are you linking with the --subsystem:console linker option?
>>
>>Original Message:
>>-----------------
>>From: steven yi stevenyi@csounds.com
>>Date: Wed, 22 Dec 2004 11:08:34 -0800
>>To: csound-dev@eartha.mills.edu
>>Subject: [CSOUND-DEV:5569] Csound4 GBS not compiling
>>
>>
>>Hi All,
>>
>>Trying to compile csound4 on my new Fedora Core 3 laptop and I get
>>
>>/usr/lib/gcc/i386-redhat/3.4.2/../../../crt1.o(.text+0x18)_: In function 
>>'_start':
>>: undefined reference to main
>>
>>This seems to happen when compiling the csound executable.  Any ideas?
>>
>>Thanks,
>>steven
>>
>>
>>--------------------------------------------------------------------
>>mail2web - Check your email from the web at
>>http://mail2web.com/ .
>>
>>
>>
>>
>>
>
> 

On 12/22/04 8:14 PM, Michael Gogins  etched in stone:

> At any rate, main is properly defined in ccsound.c, so this is quite
> puzzling.

hmmm ...

I just modified ccsound.c and this is what CVS says:

#if defined(MACOSX) && !defined(RTAUDIO)
int main(int argc, char **argv)
{
  void *csound = csoundCreate(0);
  int rc = csoundPerform(csound, argc, argv);
  csoundCleanup(csound);
  csoundReset(csound);
  csoundDestroy(csound);
  return rc;
}
#endif


Now, I HOPE that I wasn't that brain-dead when I commited this code, but I
can only conclude that I must have been.

Sorry.

Please change the first line above to

#if !defined(MACOSX) || (defined(MACOSX) && !defined(RTAUDIO))

Anthony

I just started getting mail CSOUND-DEV today, after a pause of over a
month.  In any event, something is definitely broken in ccsound.c.

John

Anthony Kozar  writes:

> #if defined(MACOSX) && !defined(RTAUDIO)

The above is definitely wrong, and the fix should work.  Shall I
commit it?

John

> int main(int argc, char **argv)
> {
>   void *csound = csoundCreate(0);
>   int rc = csoundPerform(csound, argc, argv);
>   csoundCleanup(csound);
>   csoundReset(csound);
>   csoundDestroy(csound);
>   return rc;
> }
> #endif
> 
> 
> Now, I HOPE that I wasn't that brain-dead when I commited this code, but I
> can only conclude that I must have been.
> 
> Sorry.
> 
> Please change the first line above to
> 
> #if !defined(MACOSX) || (defined(MACOSX) && !defined(RTAUDIO))
> 
> Anthony

ramsdell@mitre.org (John D. Ramsdell) writes:

> The above is definitely wrong, and the fix should work.  Shall I
> commit it?

I decided not to wait and simply commit the fix to ccsound.c.

John

you really should use __MACH__ instead of MACOSX


On Thu, 23 Dec 2004, John D. Ramsdell wrote:

> I just started getting mail CSOUND-DEV today, after a pause of over a
> month.  In any event, something is definitely broken in ccsound.c.
>
> John
>
> Anthony Kozar  writes:
>
>> #if defined(MACOSX) && !defined(RTAUDIO)
>
> The above is definitely wrong, and the fix should work.  Shall I
> commit it?
>
> John
>
>> int main(int argc, char **argv)
>> {
>>   void *csound = csoundCreate(0);
>>   int rc = csoundPerform(csound, argc, argv);
>>   csoundCleanup(csound);
>>   csoundReset(csound);
>>   csoundDestroy(csound);
>>   return rc;
>> }
>> #endif
>>
>>
>> Now, I HOPE that I wasn't that brain-dead when I commited this code, but I
>> can only conclude that I must have been.
>>
>> Sorry.
>>
>> Please change the first line above to
>>
>> #if !defined(MACOSX) || (defined(MACOSX) && !defined(RTAUDIO))
>>
>> Anthony
>
>

Anthony,

I took a close look at csound/rtcore.c and csound/ccsound.c.
Something is very wrong.  The fact that the main in routine ccsound.c
is omitted when MacOS and RTAUDIO is defined tells me the Csound
library is busted when used under those conditions.  Otherwise, why
not use the interface presented by the Csound API to start csound
using the main routine in ccsound.c?  There is no problem building the
Csound library with RTAUDIO defined on Windows and Lunix.  Is there
some reason why libcsound must be deficient in this area on OS X?

The flCsound program obtains csound support solely through the
interface provided by the Csound API.  If the library is broken on OS
X when RTAUDIO is defined, then so is flCsound.

John

Anthony Kozar  writes:

> On 12/22/04 8:14 PM, Michael Gogins  etched in stone:
> 
> > At any rate, main is properly defined in ccsound.c, so this is quite
> > puzzling.
> 
> hmmm ...
> 
> I just modified ccsound.c and this is what CVS says:
> 
> #if defined(MACOSX) && !defined(RTAUDIO)
> int main(int argc, char **argv)
> {
>   void *csound = csoundCreate(0);
>   int rc = csoundPerform(csound, argc, argv);
>   csoundCleanup(csound);
>   csoundReset(csound);
>   csoundDestroy(csound);
>   return rc;
> }
> #endif
> 
> 
> Now, I HOPE that I wasn't that brain-dead when I commited this code, but I
> can only conclude that I must have been.
> 
> Sorry.
> 
> Please change the first line above to
> 
> #if !defined(MACOSX) || (defined(MACOSX) && !defined(RTAUDIO))
> 
> Anthony

"Matt J. Ingalls"  writes:

> you really should use __MACH__ instead of MACOSX

Matt,

Perhaps you can answer this question.  Why can't the main routine in
csound/rtcore.c be purged, and the one used in csound/ccsound.c be
used on OS X just as it is for all the other platforms?  I ask you
because you are listed as one of the file's authors.

John

> On Thu, 23 Dec 2004, John D. Ramsdell wrote:
> 
> > I just started getting mail CSOUND-DEV today, after a pause of over a
> > month.  In any event, something is definitely broken in ccsound.c.
> >
> > John

Thanks guys, this fixed it. =)

John D. Ramsdell wrote:

>ramsdell@mitre.org (John D. Ramsdell) writes:
>
>  
>
>>The above is definitely wrong, and the fix should work.  Shall I
>>commit it?
>>    
>>
>
>I decided not to wait and simply commit the fix to ccsound.c.
>
>John
>
>
>
>  
>

I am not really sure how to answer your questions.  I took another look at
the code and this is what I know:

*  real-time audio was not working on OS X when ccsound.c main() was used.

*  it was working when compiling with jpff's makefile which does not use
   ccsound.c.

This is why I switched to using the main() in rtcore.c.  Further:

*  MacOS X's CoreAudio library uses a callback approach to getting the audio
   and the rtcore.c main() appears to be a simple wrapper that does nothing
   after csoundMain() returns.  This means that all of the work (musmon) is
   being run in a different thread via the CoreAudio callback.

*  I assume the reason that ccsound.c main() causes a bus error is because
   there are two threads simultaneously trying to run musmon.

*  Yes, this all implies that libcsound does not work on OS X because,
   clearly, the API must be broken.

*  Perhaps the fix is to move the "do nothing" code in rtcore.c main() when
   doing real-time into the appropriate place within the API routines.

I want to say that since I did not write this code, I really do not fully
understand it.  Matt or John ff. may be able to shed more light on all of
this than I can.  If they don't provide an answer, then I will look into a
solution.  But for now, using the main() in rtcore.c seems to be providing
OS X user's with a working GBS csound binary for real-time audio.

Anthony


On 12/23/04 2:59 PM, John D. Ramsdell  etched in stone:

> Anthony,
> 
> I took a close look at csound/rtcore.c and csound/ccsound.c.
> Something is very wrong.  The fact that the main in routine ccsound.c
> is omitted when MacOS and RTAUDIO is defined tells me the Csound
> library is busted when used under those conditions.  Otherwise, why
> not use the interface presented by the Csound API to start csound
> using the main routine in ccsound.c?  There is no problem building the
> Csound library with RTAUDIO defined on Windows and Lunix.  Is there
> some reason why libcsound must be deficient in this area on OS X?
> 
> The flCsound program obtains csound support solely through the
> interface provided by the Csound API.  If the library is broken on OS
> X when RTAUDIO is defined, then so is flCsound.
> 
> John

Anthony Kozar  writes:

> I am not really sure how to answer your questions.  I took another
> look at the code and this is what I know:
> 
> * real-time audio was not working on OS X when ccsound.c main() was
>   used.

The ccsound.c main is used by just the GBS version of a Csound 4
distribution.  The GBS distribution is committed to using Csound via
the Csound API as implemented by libcsound, and ccsound.c implements a
console version of Csound using only that API.

When I went to make it so that the GBS distribution built on OS X, I
had no idea what to do about real-time audio on the Mac.  So I punted
and set up the configuration files so they turned off real-time audio
when building a system on OS X.  I've long hoped someone knowledgeable
about real-time audio on the Mac will make Csound audio services
available to applications solely thru the Csound API.

> * it was working when compiling with jpff's makefile which does not
>   use ccsound.c.

I've been trying very hard to not break other distributions while
developing the GBS distribution.  In this case, I seem to have
succeeded.  Note that the repository holds more than just jpff's
makefiles and the GBS autotools files.  It has a couple of Microsoft
project files, and some Dev-C++ files.  Jpff is working on yet another
distribution builder using SCons.

> I want to say that since I did not write this code, I really do not
> fully understand it.

You and me both.  Thanks for all you've done.

John

Anthony Kozar  writes:

> *  I assume the reason that ccsound.c main() causes a bus error is because
>    there are two threads simultaneously trying to run musmon.

Anthony,

It just occurred to me you may be able to get a better handle on the
problem by running csound under gdb.  Gdb should give you much more
information over simply printing "bus error".

John

On 1/2/05 3:20 PM, John D. Ramsdell  etched in stone:

> Anthony Kozar  writes:
> 
>> *  I assume the reason that ccsound.c main() causes a bus error is because
>> there are two threads simultaneously trying to run musmon.
> 
> Anthony,
> 
> It just occurred to me you may be able to get a better handle on the
> problem by running csound under gdb.  Gdb should give you much more
> information over simply printing "bus error".
> 
> John
> 

I do not know anything about using gdb.  That is lame excuse but I just
haven't had the time to look into it and besides, GUI debuggers are really
easy to use.

The reason I suspect thread conflicts though is because of the crash logs OS
X automatically produces.  These logs show two or three threads running for
a console csound and show the function call stack with symbolic names.  The
logs were extremely helpful in tracking down the real-time audio bugs.

Anthony

Anthony Kozar  writes:

> The reason I suspect thread conflicts though is because of the crash
> logs OS X automatically produces.  These logs show two or three
> threads running for a console csound and show the function call
> stack with symbolic names.  The logs were extremely helpful in
> tracking down the real-time audio bugs.

It looks like you have a good handle on the problem.  From your note,
I thought you only knew you had a bus error.

John

Anthony and Matt,

I think I have a good handle on thread safe FLTK usage for Csound 4,
and tests on XP and Linux support this assertion.  Anthony, would you
check out the current contents of the repository, and give it a whirl
on OS X?  I also made it so that the GBS distribution uses the Csound
API to implement console Csound by moving some code from
csound/rtcore.c into csound/main.c.  I think I got it right.  Matt,
please look at this code and see if I'm on the right track.

John

Anthony Kozar  writes:

> I am not really sure how to answer your questions.  I took another look at
> the code and this is what I know:
> 
> *  real-time audio was not working on OS X when ccsound.c main() was used.
> 
> *  it was working when compiling with jpff's makefile which does not use
>    ccsound.c.
> 
> This is why I switched to using the main() in rtcore.c.  Further:
> 
> *  MacOS X's CoreAudio library uses a callback approach to getting the audio
>    and the rtcore.c main() appears to be a simple wrapper that does nothing
>    after csoundMain() returns.  This means that all of the work (musmon) is
>    being run in a different thread via the CoreAudio callback.
> 
> *  I assume the reason that ccsound.c main() causes a bus error is because
>    there are two threads simultaneously trying to run musmon.
> 
> *  Yes, this all implies that libcsound does not work on OS X because,
>    clearly, the API must be broken.
> 
> *  Perhaps the fix is to move the "do nothing" code in rtcore.c main() when
>    doing real-time into the appropriate place within the API routines.
> 
> I want to say that since I did not write this code, I really do not fully
> understand it.  Matt or John ff. may be able to shed more light on all of
> this than I can.  If they don't provide an answer, then I will look into a
> solution.  But for now, using the main() in rtcore.c seems to be providing
> OS X user's with a working GBS csound binary for real-time audio.
> 
> Anthony
> 
> 
> On 12/23/04 2:59 PM, John D. Ramsdell  etched in stone:
> 
> > Anthony,
> > 
> > I took a close look at csound/rtcore.c and csound/ccsound.c.
> > Something is very wrong.  The fact that the main in routine ccsound.c
> > is omitted when MacOS and RTAUDIO is defined tells me the Csound
> > library is busted when used under those conditions.  Otherwise, why
> > not use the interface presented by the Csound API to start csound
> > using the main routine in ccsound.c?  There is no problem building the
> > Csound library with RTAUDIO defined on Windows and Lunix.  Is there
> > some reason why libcsound must be deficient in this area on OS X?
> > 
> > The flCsound program obtains csound support solely through the
> > interface provided by the Csound API.  If the library is broken on OS
> > X when RTAUDIO is defined, then so is flCsound.
> > 
> > John


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks John!

Sorry that I have not been able to attempt fixing the code yet myself.

I am trying to get to the point where I can test, but I need to run a
mountain of updates first as my autotools seem to be out of date.

Anthony

On 1/29/05 4:31 PM, John D. Ramsdell  etched in stone:

> Anthony and Matt,
> 
> I think I have a good handle on thread safe FLTK usage for Csound 4,
> and tests on XP and Linux support this assertion.  Anthony, would you
> check out the current contents of the repository, and give it a whirl
> on OS X?  I also made it so that the GBS distribution uses the Csound
> API to implement console Csound by moving some code from
> csound/rtcore.c into csound/main.c.  I think I got it right.  Matt,
> please look at this code and see if I'm on the right track.
> 
> John



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net