Hi, i want to make a project with various libraries (no library does everything i want so i need to combine many) and Allegro is one of these

the only problem is that ALL libs want to control main()... and obviously only one can (trying resulted in linking errors)

is there a way in Allegro not to use the END_OF_MAIN stuff? i've tried some stuff but it just stopped working then

thanks!

Which libraries exactly are giving you problems? I think you should be able to use Allegro just fine without using END_OF_MAIN(). This as far as I can understand is just to make Allegro platform as platform independant as possible. Otherwise you'd need a WinMain if you're making a Windows program for example...

You can define ALLEGRO_NO_MAGIC_MAIN and Allegro won't take over main (though you need to make sure to have the proper entry point and everything). Though this won't work for OSX, because it needs some really funky stuff that can't be gotten around.

That is, either pass -DALLEGRO_NO_MAGIC_MAIN to the compiler (or your compiler's equivalent), or define it before including allegro.h:

#define ALLEGRO_NO_MAGIC_MAIN
#include <allegro.h>

Every library wants to take control of main? That statistic is a bit surprising to me... I would have thought it was quite a bit less.

> Though this won't work for OSX

Unfortunately i'm using OSX... not using it gives a "undefined symbol: _mangled_main_adress" linking problem (without ALLEGRO_NO_MAGIC_MAIN)

with ALLEGRO_NO_MAGIC_MAIN, it compiles fine bug i get a signal 10 (sigbus) at runtime

> Every library wants to take control of main? That statistic is a bit surprising to me... I would have thought it was quite a bit less.

Well it's only a way of speaking... i meant several libs i'm using do

What libraries are you using if several of them want to control main()?
That sounds like an odd behaviour for libraries that arent allegro-like.. but what do i know

You don't need WinMain on windows.... i've used ALLEGRO_NO_MAGIC_MAIN with a regular main functon in windows before...

> What libraries are you using if several of them want to control main()?

well... i'm a bit newbie so maybe you'll just tell me it makes no sense and i just can't do that (i've pretty much given up already)

i want to make an app using midi... so far Allegro is the only cross-platform framework doing midi playback with native drivers i've found... however Allegro's GUI capabilities are too limited for my aapp so i wanted to build a GUI in wxWidgets... wxWidgets tries to control main by default, i've found an option to disable it, it's fine but allegro doesn't work... depending on settings, i get compile errors, linking errors, or nothing happens at runtime (??)

but now i'm realizing i think both of them want to control a main loop... so maybe i couldn't have both working except maybe in different threads?

So wx and Allegro?

I didn't know wx actually mangled the main function like allegro did

If you can tell wx to no mangle main, using the two together should be relatively simple. I think, though I have no idea how to do it under osx. (allegro windows has some neat functions to handle its win32 handles.)

actually wx does not mangle main but creates a main function through preprocessor macros... the programmer instead uses a Init() method

however, as i said, i turned on an option to manually declare main, wx is working fine, but END_OF_MAIN() doesn't work and says: "undefined symbol: _main" i don't know why, main is there, and wx configured not to control main. however, the second i remove wx, allegro works fine again

if i use ALLEGRO_NO_MAGIC_MAIN, it compiles and launches, but allegro crashes with signal 10 sigbus

or maybe... are there specific compiler flags tha allegro takes... wx takes quite a bit of special compiler configuration, some of which wx-config just told me to put there and i'm not 100% sure what they are... linking libs and stuff i believe so shouldn't create problems?

As was said, allegro can't work without the mangled main in OSX. So it seems that even once you tell wx to not controll main, it decides to mangle it in some way?

> So it seems that even once you tell wx to not controll main, it decides to mangle it in some way?

i don't know... i would have thought it wouldn't, but it doesn't work, so it could be it... there's no workaround then, right?

You'll have to ask someone with more Wx knowledge, as I have very little.

http://www.allegro.cc/forums/thread/495839

BAF, you sure that will help him get it to work in OSX? Your code in that thread is for windows

I may be pushing into OT territory, but have you considered using Qt4? It's cross-platform (it uses native widgets where possible), and though it's C++ instead of C, you may have better luck with the main() override problem. I am biased though, since wxWidgets uses GTK by default, and GTK apps look like ass to me.

If all you need Allegro for is MIDI playback, have you looked at other libs? As much as I like Allegro, I'll be the first to admit it's MIDI handling is.. bad. Sure it "works", but barely (most of the time, the only way to get MIDI is to use the DIGMID driver, which is built-in software wavetable driver; and a big hack, at that, since it does things you're not supposed to do). Unfortunately I can't think of many other cross-platform MIDI libraries. Any reason you want to use MIDI instead of modules (MOD, IT, etc) or Ogg?

If you do decide to go with Qt, I'd gladly be a mentor

edit, to add to what KC there said about MIDI, allegro's player isnt quite 100%, it isnt 100% compatible with many midi files, and the DIGIMID driver can't handle some of the "effects".. So if you have to have music, I'd go with modules, or ogg.

Doesn't work reliably though. We tried that a couple of years ago; I think it worked in some situations but not in others (could be MinGW vs MSVC).
Unless you mean for what MS insists on calling a console application.

No, it works reliably. If you are compiling a Win32 application, gcc may have fallen back on a main function if it was available. MSVC will not. You can pass a command line option to MSVC to redefine the entry point.

I don't understand what you are trying to say by this... it sounds very derogatory

i'm trying things, right now i just want to reply to tons of wrong stuff i,ve read about wx

wait... i'm on mac... you're mixing up platforms!

wxWidgets and Allegro are both cross-platform stuff, so code should be the same on all platforms

i'll try these code snippets and i'll come back

wx is C++ too (??)

Qt 3 for mac was pure s**t
I don't know about Qt 4 though

wx uses native APIs... GTK is for Linux/Unix! i'm on mac, wx uses Carbon

yes i've looked at many other libs... many good cross-platform libs offer midi manipulation, midi input from devices, but i haven,t found any that offers playback
(i absolutely need cross-platform)

actually i've lookd at MOD/IT too, i'd like to have them in addition of midi

EDIT: i tried running the samples from the thread someone posted... it seems like wx+Allegro only work without magic_main... which isn't supportd on mac

guess i'll just drop it

Are we talking about the same thing?
What I mean is having a regular main() function that that results in a fully functional normal Win32 GUI application. As far as I know, you can't do that and it didn't work properly when we tried it a couple of years ago.
If you know how to get this to work, can you submit a patch yesterday to remove END_OF_MAIN() for Windows?

I was in a hurry, hence MS for Microsoft.
What I meant is that they make a distinction between a `console' and a `GUI' application, based on wether the programme has a WinMain() or a main() function. I think this is distinction is artificial, unnescessary. silly and pointless (not to mention that it makes it harder to port programmes from other operating systems).

Like I said, you need to tell cl with a command-line switch to use main as the entry point instead of WinMain. There might be a pragma for that, but I doubt it.

Yeah, I am sure the only reason they had for doing so it to be able to change the parameters, which is easily avoided. Oh well. It goes without saying they didn't have portability in midn when they designed this

Ok. So can you make the patch or not?
Or get someone else to do it?

EDIT: Oh wait... never mind... it doesn't help if we need a special switch when linking against Allegro, does it?

It's possible the program's crashing for some other reason, such as loading bitmaps before allegro_init() or something. Can you gdb the core file? Or perhaps have it write "progress report" messages to a file as it goes, where the file ends should tell you approximately where it's crashing. (maybe want to close the file after each message, then reopen it for next message)

no, the code i've tried is sure to be valid, it works on Windows - the crash occurs on allegro_init, most probably because the pointer to main is wrong (if i understaood correctly what END_OF_MAIN does)

Except that he used win_* api functions that are only available on allegro for windows.