I am trying to install SDL_image framework for OS X. the SDL one seems
to have installed very cleanly. The SDL_image one claims to be
installed but is nowhere to be found. Any ideas?
Also I am planning to make an SDL dependent library a framework as
well… any advice?
Thanks
@end
Dave
I am trying to install SDL_image framework for OS X. the SDL one seems
to have installed very cleanly. The SDL_image one claims to be
installed but is nowhere to be found. Any ideas?
A few weeks ago I fixed the projects that build the installers for
Mac OS X (for all the projects hosted on libsdl.org). Sam hasn’t found
the time to integrate them into CVS quite yet. In the meantime you can
grab them at:
http://icdweb.cc.purdue.edu/~walisser/sdl/org.libsdl.PBProjects.tar.gz
and compile an installer that should work correctly. If you run into
trouble grab the latest source from CVS. If you still have trouble I’ll
try my best to help you out 
Also I am planning to make an SDL dependent library a framework as
well… any advice?
Try using the projects I’ve created as an example. If you have any
additional questions feel free to email me.
Cheers,
DarrellOn Saturday, February 23, 2002, at 07:16 PM, David Leimbach wrote:
Hi Darrell or any other MacOS developer,
Just as a matter of interest what is the MacOS equivalent of the
Dynamic Linked Library or Shared Object for SDL called?
Does it have a particular filename extentions like under Windows and Linux?
The reason I ask is because I am trying to pre-empt the possibility that
FreePascal and Delphi/Kylix will support MacOS soon and I would like my
header to be ready.
Thanks,
http://www.DelphiGamer.com := for all your Object Pascal game
development needs;
http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME := Home of JEDI-SDL;
Cross-platform game development with Pascal, has never been easier.
Darrell Walisser wrote:>
On Saturday, February 23, 2002, at 07:16 PM, David Leimbach wrote:
I am trying to install SDL_image framework for OS X. the SDL one
seems to have installed very cleanly. The SDL_image one claims to be
installed but is nowhere to be found. Any ideas?A few weeks ago I fixed the projects that build the installers forMac OS X (for all the projects hosted on libsdl.org). Sam hasn’t found
the time to integrate them into CVS quite yet. In the meantime you can
grab them at:http://icdweb.cc.purdue.edu/~walisser/sdl/org.libsdl.PBProjects.tar.gz
and compile an installer that should work correctly. If you run into
trouble grab the latest source from CVS. If you still have trouble I’ll
try my best to help you outAlso I am planning to make an SDL dependent library a framework as
well… any advice?Try using the projects I’ve created as an example. If you have any
additional questions feel free to email me.Cheers,
Darrell
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi Darrell or any other MacOS developer,
Just as a matter of interest what is the MacOS equivalent of the
Dynamic Linked Library or Shared Object for SDL called?
Does it have a particular filename extentions like under Windows and
Linux?
.dylib its a Mach-o object I believeOn Saturday, February 23, 2002, at 07:38 PM, Dominique Louis wrote:
The reason I ask is because I am trying to pre-empt the possibility
that FreePascal and Delphi/Kylix will support MacOS soon and I would
like my header to be ready.Thanks,
http://www.DelphiGamer.com := for all your Object Pascal game
development needs;
http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME := Home of JEDI-SDL;
Cross-platform game development with Pascal, has never been easier.Darrell Walisser wrote:
On Saturday, February 23, 2002, at 07:16 PM, David Leimbach wrote:
I am trying to install SDL_image framework for OS X. the SDL one
seems to have installed very cleanly. The SDL_image one claims to be
installed but is nowhere to be found. Any ideas?
A few weeks ago I fixed the projects that build the installers for
Mac OS X (for all the projects hosted on libsdl.org). Sam hasn’t found
the time to integrate them into CVS quite yet. In the meantime you can
grab them at:
http://icdweb.cc.purdue.edu/~walisser/sdl/org.libsdl.PBProjects.tar.gz
and compile an installer that should work correctly. If you run into
trouble grab the latest source from CVS. If you still have trouble
I’ll try my best to help you outAlso I am planning to make an SDL dependent library a framework as
well… any advice?
Try using the projects I’ve created as an example. If you have any
additional questions feel free to email me.
Cheers,
Darrell
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
At 1:38 Uhr +0000 24.02.2002, Dominique Louis wrote:
Hi Darrell or any other MacOS developer,
Just as a matter of interest what is the MacOS equivalent of the
Dynamic Linked Library or Shared Object for SDL called?
Does it have a particular filename extentions like under Windows and Linux?
If you talk about OS X, the extension for a “shared library” is
.dylib. The extension for a “loadable module” is usually .so (though
nothing forces you to use that, just a convention. That’s the core,
and what the automake based build system of SDL creates on MacOS X
(.dylibs that is).
The high-level bretheren of these are Frameworks (.framework, shared
library, but can include multiple versions, meta-data, header files,
resources like images, documentation etc.), and Plugin Bundles
(.bundle usually, but can be anything; again, this can contain
additional data). The Project Builder based build system of SDL
creates Frameworks.
If you want to know about a MacOS 9, that’s a whole different beast.
But since you ask regarding FreePascal/Kylix, I bet that’s not what
interests you 
The reason I ask is because I am trying to pre-empt the possibility
that FreePascal and Delphi/Kylix will support MacOS soon and I would
like my header to be ready.
Hm, AFAIK the chance to see Kylix on OS X are pretty slim, especially
in a state where it is usable to produce “real” MacOS X apps (i.e.
giving you access more than just the core BSD APIs). Do you have any
reason to believe differently? I’m just curious.
Max Horn
Software Developer
email: mailto:Max_Horn
phone: (+49) 6151-494890
At 1:38 Uhr +0000 24.02.2002, Dominique Louis wrote:
Hi Darrell or any other MacOS developer,
Just as a matter of interest what is the MacOS equivalent of the
Dynamic Linked Library or Shared Object for SDL called?
Does it have a particular filename extentions like under Windows and
Linux?If you talk about OS X, the extension for a “shared library” is .dylib.
The extension for a “loadable module” is usually .so (though nothing
forces you to use that, just a convention. That’s the core, and what
the automake based build system of SDL creates on MacOS X (.dylibs that
is).
I only ever get static to work so I never see dylibs come out of the
automake based SDL build on OS X. Is this different in CVS? [I need to
reverify this but I distinctly remember wanting to use frameworks as a
result of failed attempts to build a shared library of the following:
SDL and SDL_image].
The high-level bretheren of these are Frameworks (.framework, shared
library, but can include multiple versions, meta-data, header files,
resources like images, documentation etc.), and Plugin Bundles (.bundle
usually, but can be anything; again, this can contain additional data).
The Project Builder based build system of SDL creates Frameworks.
This Framework idea is really exciting IMHO. Header files and libs all
in one place. The framework itself can be thought of as a directory of
all the stuff you need for the framework contained in one place. In
fact it exists as a directory on disk much like Cocoa apps are
directories on disk with a binary hidden in a deeper subdirectory.
In the gui frameworks show up as directories while *.app’s show up as
"files". These files are really directories on disk but the command
line “open” can run these special directories as if you had double
clicked them in the GUI. [“openapp” in GNUstep for you linux/Unix
non-OSX fans can do the same thing provided your GNUstep environment is
up and running/]
Hm, AFAIK the chance to see Kylix on OS X are pretty slim, especially
in a state where it is usable to produce “real” MacOS X apps (i.e.
giving you access more than just the core BSD APIs). Do you have any
reason to believe differently? I’m just curious.
I think Max is correct unless someone has an inside information we
don’t. The ability to use Cocoa will require objective-c and frameworks
support [maybe it can be done with Cocoa’s other native language -
java]. If you aren’t using Cocoa you are using Carbon to code for
Aqua. Cocoa is, by things I have read on apple’s site, going to be only
API of the two that they continue to support and develop in the long
term. Carbon is there to get your app to OS X quickly while you work on
Cocoa-ifying it as far as I can see.
Now I suppose you could write Kylix to use QT on OS X but even QT uses
Carbon and then you are simply adding another layer of
Kylix->C+±>QT->Carbon->Quartz. So Kylix doesn’t seem a likely
candidate for OSX unless they wrap up the whole Carbon or Cocoa API in
Kylix [pascal-like] code [this is presuming that Kylix needs a special
ABI to call on Cocoa/Carbon functions].
Blah… this all has nothing to do with SDL directly.On Sunday, February 24, 2002, at 07:34 AM, Max Horn wrote:
Max
Max Horn
Software Developeremail: <mailto:max at quendi.de>
phone: (+49) 6151-494890
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hi Max,
Max Horn wrote:
At 1:38 Uhr +0000 24.02.2002, Dominique Louis wrote:
If you talk about OS X, the extension for a “shared library” is .dylib.
The extension for a “loadable module” is usually .so (though nothing
forces you to use that, just a convention. That’s the core, and what the
automake based build system of SDL creates on MacOS X (.dylibs that is).The high-level bretheren of these are Frameworks (.framework, shared
library, but can include multiple versions, meta-data, header files,
resources like images, documentation etc.), and Plugin Bundles (.bundle
usually, but can be anything; again, this can contain additional data).
The Project Builder based build system of SDL creates Frameworks.
I suppose then my question should be how is the SDL suite ( SDL,
SDL_Image, SDL_Mixer etc ) implemented under MacOSX? Does it use .dylib
or these frameworks you mention?
If you want to know about a MacOS 9, that’s a whole different beast. But
since you ask regarding FreePascal/Kylix, I bet that’s not what
interests you
As mentioned above, I am unsure. Currently Delphi, Kylix and FreePascal
make use of SDL.dll on Windows and libSDL.1.2.so.0 on Linux and this is
the same for SDL_Mixer, SDL_Image, SDL_Sound and SDL_Net as well. So I
have assumed ( maybe wrongly ) that the equivalent would be these .dylib
files.
Hm, AFAIK the chance to see Kylix on OS X are pretty slim, especially in
a state where it is usable to produce “real” MacOS X apps (i.e. giving
you access more than just the core BSD APIs). Do you have any reason to
believe differently? I’m just curious.
Is QT supported under MacOSX? Currently Kylix creates a C wrapper to
talk to the QT libs on Linux and thought that maybe there could be
something similar on MacOSX. Or am I barking up the wrong tree.
If the folks at Borland ( or FreePascal ) can do something similar, then
it follows Borland’s current strategy of trying to bring out a range of
cross-platform tools to MacOS as well. They already support JBuilder on
MacOS and since Object Pascal was originally borrowed from Apple I
thought they might want to take it back home :).
Thanks for the background information on MacOS. It is always good to get
an insight into how things work under other Operating Systems.
L8R,
Dominique.–
http://www.DelphiGamer.com := for all your Object Pascal game
development needs;
http://www.delphi-jedi.org/Jedi:TEAM_SDL_HOME := Home of JEDI-SDL;
Cross-platform game development with Pascal, has never been easier.
I suppose then my question should be how is the SDL suite ( SDL,
SDL_Image, SDL_Mixer etc ) implemented under MacOSX? Does it use .dylib
or these frameworks you mention?
You can pick one. It seems that you can compile either option.
If you want to know about a MacOS 9, that’s a whole different beast.
But since you ask regarding FreePascal/Kylix, I bet that’s not what
interests youAs mentioned above, I am unsure. Currently Delphi, Kylix and FreePascal
make use of SDL.dll on Windows and libSDL.1.2.so.0 on Linux and this is
the same for SDL_Mixer, SDL_Image, SDL_Sound and SDL_Net as well. So I
have assumed ( maybe wrongly ) that the equivalent would be these
.dylib files.Hm, AFAIK the chance to see Kylix on OS X are pretty slim, especially
in a state where it is usable to produce “real” MacOS X apps (i.e.
giving you access more than just the core BSD APIs). Do you have any
reason tobelieve differently? I’m just curious.
Is QT supported under MacOSX? Currently Kylix creates a C wrapper to
talk to the QT libs on Linux and thought that maybe there could be
something similar on MacOSX. Or am I barking up the wrong tree.
If the folks at Borland ( or FreePascal ) can do something similar,
then it follows Borland’s current strategy of trying to bring out a
range of cross-platform tools to MacOS as well. They already support
JBuilder on MacOS and since Object Pascal was originally borrowed from
Apple I thought they might want to take it back home :).
Yes QT is available for OS X. If Kylix uses C wrappers to make a QT
interface than it is clear that it uses C style linkage to call
functions. This may be enough for Carbon but isn’t for Cocoa. So I
suppose it would be possible to use Kylix with C bindings on OSX.
Thanks for the background information on MacOS. It is always good to
get an insight into how things work under other Operating Systems.
yeah… OSX is a slightly different animal. Its got static, shared, and
Frameworks and as far as I can tell frameworks require some objective C
to get the environment going… [Please correct me if I am wrong… I am
fairly new to some of this and my understanding is just what I can piece
together from code I have read and some online docs]
I think that as long as you have SDLMain.m compiled into your SDL
framework that Kylix may be able to use the rest of libraries C bindings
to get the job done.
Of course this is just a guess
At 9:00 Uhr -0600 24.02.2002, David Leimbach wrote:
At 1:38 Uhr +0000 24.02.2002, Dominique Louis wrote:
[…]
I only ever get static to work so I never see dylibs come out of the
automake based SDL build on OS X. Is this different in CVS? [I need to reverify this but I distinctly remember wanting to use frameworks as a result of failed attempts to build a shared library of the following: SDL and SDL_image].
You can produce shared libs with them, but you have to make sure you
use the right version of libtool. The non-CVS version ship with a
libtool version that can’t build dynamic libs on OS X. If you use
e.g. libtool 1.4.2 with CVS, or the patched ltmain.sh / ltconfig for
1.3.5 (which we provide at
http://fink.sourceforge.net/doc/porting/libtool.php#patch-135), it
works. In Fink I used this for the SDL packages (see
http://fink.sourceforge.net/pdb/package.php/sdl)
However, let me say this now: I don’t think one should use shared
libraries for most apps that use SDL. That is, it’s OK to use SDL
shared libs during development, but when you ship it, do yourself and
your customers a favor and static link SDL.
[…]
Hm, AFAIK the chance to see Kylix on OS X are pretty slim,
especially in a state where it is usable to produce “real” MacOS X
apps (i.e. giving you access more than just the core BSD APIs). Do
you have any reason to believe differently? I’m just curious.I think Max is correct unless someone has an inside information we
don’t. The ability to use Cocoa will require objective-c and
frameworks support [maybe it can be done with Cocoa’s other native
language - java].
That’s not fully true. There exists Cocoa wrappers for Tcl/Tk
(provided by Apple!), and internally they have some Perl wrappers
(though this is not release, since the guy who hacked it up has had
no time so far to publish it - they use this for the internal OS
build system). Also, I think I saw some neat Ruby wrappers at
SourceForge. So it is possible, although I think that you loose a lot
elegance if you code in something different from Objective C. I just
love that language =)
If you aren’t using Cocoa you are using Carbon to code for Aqua.
Cocoa is, by things I have read on apple’s site, going to be only
API of the two that they continue to support and develop in the long
term. Carbon is there to get your app to OS X quickly while you
work on Cocoa-ifying it as far as I can see.
Nah, not the full truth… Carbon isn’t going away for a long time.
At least not for the next 5-10 years. And the new Carbon APIs are
themselves quite nice. Though I personally almost only code in Cocoa
these days, it’s just a programmers dream come true
Now I suppose you could write Kylix to use QT on OS X but even QT
uses Carbon and then you are simply adding another layer of
Kylix->C+±>QT->Carbon->Quartz. So Kylix doesn’t seem a likely
candidate for OSX unless they wrap up the whole Carbon or Cocoa API
in Kylix [pascal-like] code [this is presuming that Kylix needs a
special ABI to call on Cocoa/Carbon functions].Blah… this all has nothing to do with SDL directly.
Yes =)>On Sunday, February 24, 2002, at 07:34 AM, Max Horn wrote:
Max Horn
Software Developer
email: mailto:Max_Horn
phone: (+49) 6151-494890
At 18:23 Uhr +0000 24.02.2002, Dominique Louis wrote:
Hi Max,
Max Horn wrote:
At 1:38 Uhr +0000 24.02.2002, Dominique Louis wrote:
If you talk about OS X, the extension for a “shared library” is
.dylib. The extension for a “loadable module” is usually .so
(though nothing forces you to use that, just a convention. That’s
the core, and what the automake based build system of SDL creates
on MacOS X (.dylibs that is).The high-level bretheren of these are Frameworks (.framework,
shared library, but can include multiple versions, meta-data,
header files, resources like images, documentation etc.), and
Plugin Bundles (.bundle usually, but can be anything; again, this
can contain additional data). The Project Builder based build
system of SDL creates Frameworks.I suppose then my question should be how is the SDL suite ( SDL,
SDL_Image, SDL_Mixer etc ) implemented under MacOSX? Does it use
.dylib or these frameworks you mention?
Read again, I explained it :-). You can have both. Framerworks are
built in the Project Builder build system, while the automake based
one build .dylibs directly.
[…]
Is QT supported under MacOSX? Currently Kylix creates a C wrapper to
talk to the QT libs on Linux and thought that maybe there could be
something similar on MacOSX. Or am I barking up the wrong tree.
Sure that would be possible, but as David correctly said, it would be
quite awkward: a wrapper around a wrapper which wraps a wrapper. Ugh.
If the folks at Borland ( or FreePascal ) can do something similar,
then it follows Borland’s current strategy of trying to bring out a
range of cross-platform tools to MacOS as well. They already support
JBuilder on MacOS
That’s a very different thing, it’s Java based.
and since Object Pascal was originally borrowed from Apple I
thought they might want to take it back home :).Thanks for the background information on MacOS. It is always good to
get an insight into how things work under other Operating Systems.
You’re welcome
Max Horn
Software Developer
email: mailto:Max_Horn
phone: (+49) 6151-494890
At 12:53 Uhr -0600 24.02.2002, David Leimbach wrote:
[…]
yeah… OSX is a slightly different animal. Its got static, shared,
and Frameworks and as far as I can tell frameworks require some
objective C to get the environment going… [Please correct me if I
am wrong… I am fairly new to some of this and my understanding is
just what I can piece together from code I have read and some online
docs]
Not correct, Frameworks are not tied to a particular language. If you
prefer assembler, that’s fine, too (though probably quite some more
work
Max Horn
Software Developer
email: mailto:Max_Horn
phone: (+49) 6151-494890
However, let me say this now: I don’t think one should use shared
libraries for most apps that use SDL. That is, it’s OK to use SDL
shared libs during development, but when you ship it, do yourself and
your customers a favor and static link SDL.
Oh yeah… tell me about it
[…]
Hm, AFAIK the chance to see Kylix on OS X are pretty slim, especially
in a state where it is usable to produce “real” MacOS X apps (i.e.
giving you access more than just the core BSD APIs). Do you have any
reason to believe differently? I’m just curious.I think Max is correct unless someone has an inside information we
don’t. The ability to use Cocoa will require objective-c and
frameworks support [maybe it can be done with Cocoa’s other native
language - java].That’s not fully true. There exists Cocoa wrappers for Tcl/Tk (provided
by Apple!), and internally they have some Perl wrappers (though this is
not release, since the guy who hacked it up has had no time so far to
publish it - they use this for the internal OS build system). Also, I
think I saw some neat Ruby wrappers at SourceForge. So it is possible,
although I think that you loose a lot elegance if you code in something
different from Objective C. I just love that language =)
Objective C or Ruby you love?
If you aren’t using Cocoa you are using Carbon to code for Aqua.
Cocoa is, by things I have read on apple’s site, going to be only API
of the two that they continue to support and develop in the long
term. Carbon is there to get your app to OS X quickly while you work
on Cocoa-ifying it as far as I can see.Nah, not the full truth… Carbon isn’t going away for a long time. At
least not for the next 5-10 years. And the new Carbon APIs are
themselves quite nice. Though I personally almost only code in Cocoa
these days, it’s just a programmers dream come true
Objective C? I read and watched Apple media saying that Carbon is not a
future looking API. I would assume that it won’t be around in the
future… do what you will with that info but for me it means if you
want to code on OS X learn Objective C
However, let me say this now: I don’t think one should use shared
libraries for most apps that use SDL. That is, it’s OK to use SDL
shared libs during development, but when you ship it, do yourself and
your customers a favor and static link SDL.Oh yeah… tell me about it
In the new project files for SDL*, you can put the frameworks into
Myapp.app/Contents/Frameworks/ and bundle them with the application
instead of requiring a separate install. I’m currently doing this for
the next release of GLTron and it works great. (FYI, you can do this
with any framework by setting the “install path” in Project Builder to
"@executable_path/…/Frameworks").
-DOn Sunday, February 24, 2002, at 04:36 PM, David Leimbach wrote:
At 18:18 Uhr -0500 24.02.2002, Darrell Walisser wrote:>On Sunday, February 24, 2002, at 04:36 PM, David Leimbach wrote:
However, let me say this now: I don’t think one should use shared
libraries for most apps that use SDL. That is, it’s OK to use SDL
shared libs during development, but when you ship it, do yourself
and your customers a favor and static link SDL.Oh yeah… tell me about it
In the new project files for SDL*, you can put the frameworks into
Myapp.app/Contents/Frameworks/ and bundle them with the application
instead of requiring a separate install. I’m currently doing this
for the next release of GLTron and it works great. (FYI, you can do
this with any framework by setting the “install path” in Project
Builder to “@executable_path/…/Frameworks”).
Yes you can do that, but you waste disk space this way. I still don’t
see why you would want to do that with SDL =)
Max Horn
Software Developer
email: mailto:Max_Horn
phone: (+49) 6151-494890