Has anyone published an SDL 1.3 app on the Mac App Store?

I’m curious, because when I submit using Application Loader, I get:

Package “com.actionsoft.midnightmansionepisode1”: Bundle at “MM.app/Contents/Frameworks/SDL.framework” in Payload not declared in PackageInfo.

I’ve renamed the bundle identifier to “com.libsdl.sdl” because initially Application Loaded complained that “SDL” was not a valid bundle identifier. I’ve also verified that this bundle identifier is unique. I don’t know what else to try, aside from “com.actionsoft.sdl” (same naming scheme as my app). This is based on Apple’s FAQ for this issue, see below.

I’m wondering, has anyone else published a Mac app via the Mac App Store using SDL 1.3?? How did you get around this issue?------------

  1. I’m receiving a “Payload not declared in PackageInfo” error when using Application Loader. What’s going wrong and how can I fix this?
    This error typically occurs when embedding bundles (including frameworks) inside your app bundle. When including bundles inside your app, it’s particularly important that you ensure they have unique bundle identifiers that match your company’s naming scheme. You can also run into this problem if your app contains multiple bundles that each have the same bundle identifier. As always, ensure sure you do not leave your bundle identifier as com.yourcompany.yourcocoaframework and that each identifier is unique within your bundle.

A similar problem can occur if your app includes a helper application and both apps reference a common bundle. Suppose your app contains and uses FooBundle and your helper app also contains and uses its own copy of FooBundle. Since both of these copies of FooBundle are identical, they have the same bundle identifier. Furthermore, since both of them are located inside your app bundle as a whole, you will receive the above error message. Instead, you should provide a common location in your app bundle that both your app and your helper application can reference when they need FooBundle.

I just got Scruffy3D “Waiting for Review” at the mac app store. It was
a hassle and half for at least 2 days or figuring out everything I had
to get in there for it to be accepted.

It uses SDL 1.2.whatever the latest was (SDL 1.3 isn’t usable until
relative mouse gets in there – luckily it’s an OpenGL app so I should
be OK). I eventually gave up with all the framework and dylib problems,
and compiled all my libraries to static libs, and bypassed all those
types of problems. It actually has a side benefit of making my
windows/OS X code base closer (as no frameworks in windows.) Another
side benefit – the llvm compiler better handles inlining and other
things when statically linked, and “link time optimizations” kills DWARF
with dSYM, which you need in the appstore.

Yes, it’s annoying, but it fixed a lot of nonsense that I wasn’t getting
proper error messages for and didn’t feel like using hours of trial and
error to figure it out.

Even worse, the XCode Archive option always failed for me, I had to
package it by hand!

Bottom line: Apple could probably make this better in a number of ways!

BTW: How’s relative mouse coming? :slight_smile:

[>] Brian

It uses SDL 1.2.whatever the latest was (SDL 1.3 isn’t usable until
relative mouse gets in there – luckily it’s an OpenGL app so I should be
OK). I eventually gave up with all the framework and dylib problems, and
compiled all my libraries to static libs,

Isn’t SDL 1.2.* LGPL ? How do you allow relinking of your OpenGL
application, do you provide the object files or source?On 18 July 2011 18:20, Brian Barnes wrote:

LGPL doesn’t require the source for your application, just for the library
and any modifications to it. Anyways, wasn’t SDL re-released under some
other (more permissive) license just recently?

PatrickOn Mon, Jul 18, 2011 at 1:01 PM, liam mail <liam.list at googlemail.com> wrote:

On 18 July 2011 18:20, Brian Barnes wrote:

It uses SDL 1.2.whatever the latest was (SDL 1.3 isn’t usable until
relative mouse gets in there – luckily it’s an OpenGL app so I should be
OK). I eventually gave up with all the framework and dylib problems, and
compiled all my libraries to static libs,

Isn’t SDL 1.2.* LGPL ? How do you allow relinking of your OpenGL
application, do you provide the object files or source?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Brian – are you the author of “Scruffy” (or maybe it was “Scruffy II”) from way back in the B&W Mac days? And “Billy Goes Bowling”? If so, man – I loved that old Scruffy game back in the day! (And I think I spoke to you by email back then about it at one point.) Haha, small world.

Anyway, any chance you could give me any tips on how to compile the libraries as static libs? I tried doing the UNIX style ./configure and make, but I don’t even know where the end results were put, or what libraries I’d want to link to. Or is there a way to configure XCode to make static libs?

LGPL doesn’t require the source for your application, just for the library
and any modifications to it. Anyways, wasn’t SDL re-released under some
other (more permissive) license just recently?

Patrick

It uses SDL 1.2.whatever the latest was (SDL 1.3 isn’t usable until
relative mouse gets in there – luckily it’s an OpenGL app so I should be
OK). I eventually gave up with all the framework and dylib problems, and
compiled all my libraries to static libs,

Isn’t SDL 1.2.* LGPL ? How do you allow relinking of your OpenGL
application, do you provide the object files or source?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

LGPL when statically linked requires either source or object files so that
you can relink another version of the LGPL library. IIRC it was only 1.3
which got a licence change as otherwise it would require authorisation from
all <=1.2.* authors. Unless I have missed this announcement.On 18 July 2011 19:10, Patrick Baggett <baggett.patrick at gmail.com> wrote:

On Mon, Jul 18, 2011 at 1:01 PM, liam mail <@liam_mail>wrote:

On 18 July 2011 18:20, Brian Barnes wrote:

LGPL doesn’t require the source for your application, just for the library
and any modifications to it. Anyways, wasn’t SDL re-released under some
other (more permissive) license just recently?

Patrick

It uses SDL 1.2.whatever the latest was (SDL 1.3 isn’t usable until
relative mouse gets in there – luckily it’s an OpenGL app so I should be
OK). I eventually gave up with all the framework and dylib problems, and
compiled all my libraries to static libs,

Isn’t SDL 1.2.* LGPL ? How do you allow relinking of your OpenGL
application, do you provide the object files or source?


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

LGPL when statically linked requires either source or object files so that
you can relink another version of the LGPL library. IIRC it was only 1.3
which got a licence change as otherwise it would require authorisation from
all <=1.2.* authors. Unless I have missed this announcement.

I have just seen the OP has confirmed that the source is available, wrutten
in one of the other three email threads with the same topic header :)On 18 July 2011 21:11, liam mail <@liam_mail> wrote:

On 18 July 2011 19:10, Patrick Baggett <baggett.patrick at gmail.com> wrote:

On Mon, Jul 18, 2011 at 1:01 PM, liam mail <@liam_mail>wrote:

On 18 July 2011 18:20, Brian Barnes wrote:

Close, its in the review process,

Apple reviewers didn’t see any issue with our sdl implementation.
Approval held up because of the new inapp subscription changes, but they are helping us get a quick approval.

We are a commercial licensed sdl user, however.

michelleC wrote:

We are a commercial licensed sdl user, however.

Could that be the issue? I’m about to pay the $500 license fee, but I didn’t think it made any difference to the library…

VernJensen wrote:

michelleC wrote:

We are a commercial licensed sdl user, however.

Could that be the issue? I’m about to pay the $500 license fee, but I didn’t think it made any difference to the library…

What issue would the license make a difference with.

Sdl is built as libsdl.a

As Sam spelled out in his farewell email when he shut down Galaxy Gameworks, SDL 1.3 core libraries maintained by Sam and Ryan went zlib license for all to use (SDL, SDL_mixer, SDL_image at least, I
may be forgetting others - SDL_ttf?) so there is no license fee anymore, nor any effort involved, they can be freely static linked without consequence, it is good to put a note about using SDL
however, and of course putting the app on the libsdl site as an app using SDL is a nice courtesy.

So SDL 1.3 should be perfectly safe to use on the Mac appstore (also the iOS appstore for what it’s worth).

SDL 1.2 is not affected (still LGPL, and was never up for commercial licensing).On 07/18/2011 03:36 PM, VernJensen wrote:

michelleC wrote:

We are a commercial licensed sdl user, however.

Could that be the issue? I’m about to pay the $500 license fee, but I didn’t think it made any difference to the library…


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier

Oh! I hadn’t seen that email from Sam. Found it now in the forum archives. Thanks, good to know.

LGPL when statically linked requires either source or object files so
that you can relink another version of the LGPL library. IIRC it was
only 1.3 which got a licence change as otherwise it would require
authorisation from all <=1.2.* authors. Unless I have missed this
announcement.

I’m replying to this late, and the project in question is open source so
it doesn’t matter in this case, but to answer the question: 1.3 is under
the zlib license, but 1.2 is still LGPL. We couldn’t relicense it
because we can’t account for all the code in it. Some of it, like the
Hermes blitters, were dropped in wholesale from an external project,
other parts were written by people that just drifted through. Some
contributors to 1.2 are even dead, and can’t authorize a license change.

For 1.3, everything was either ripped out, rewritten, or we got
permission to relicense from the original author.

I don’t personally care if someone statically links 1.2, but I don’t
speak for anyone else, and I don’t even have a complete list of people
that may or may not care.

In such a case: you take at least a small risk in shipping a closed
source program, statically linked to SDL 1.2. The reason for dynamic
linking in the LGPL is so that people can, at their option, replace the
SDL you ship with their own build.

If you’re closed source and using SDL 1.2, ship SDL as a shared
library/.dylib/.dll/framework. If you really MUST ship a
statically-linked version, the letter of the license allows you to hand
everyone a pile of object files, so they can relink your app with SDL,
but this seems like a huge pain for everyone.

If you can get away with migrating to SDL 1.3 at this point, you can
statically link THAT, but I understand that’s not always a reasonable
option yet.

–ryan.

It’s 1.3 that I’m trying to use. I’m quite simply looking for any method of getting the Mac App Store to accept my SDL 1.3-using app. So far no success! It gets rejected if included as a framework (and I still haven’t figured out why), and I get linker errors if I try to use SDL 1.3 as a static library.

Vern – is it the archiver that’s causing you the problem? The archiver is completely and utterly broken, and it’s no better in 4.1.

If this is your problem, use the project build command line tool:

productbuild --component VERN.app /Applications --sign “3rd Party Mac Developer Installer: VERN” VERN.pkg

Then use application loader (it’ll be in your development package) to upload it.

Scruffy3D (everybody go and look!) is up in the App Store right now!

[>] Brian

Brian Barnes wrote:> Vern – is it the archiver that’s causing you the problem? The archiver is completely and utterly broken, and it’s no better in 4.1.

If this is your problem, use the project build command line tool:

productbuild --component VERN.app /Applications --sign “3rd Party Mac Developer Installer: VERN” VERN.pkg

Then use application loader (it’ll be in your development package) to upload it.

Scruffy3D (everybody go and look!) is up in the App Store right now!

[>] Brian

No, I’ve tried using both XCode and productbuild to submit. I get the same error in the end. Something about the SDL.framework not being declared in packageInfo or something like that. Apple has a FAQ about this on their forums – that it means multiple frameworks are using the same Bundle Identifier, but this is no the case. I’ve tried all sort of variations for different bundle identifiers for the SDL.framework, but none work.

I’m guessing Scruffy3D uses SDL 1.2.x. I’m using SDL 1.3. So far I’ve heard from no one who has used SDL 1.3 to get an app on the Mac App Store.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Do you have white space in your app name? This link suggests it broke
Application Loader:
http://forums.realsoftware.com/viewtopic.php?f=7&t=36655

Other posts suggest people have embedded Qt frameworks and MacRuby,
both of which are far more intrusive than SDL. (One MacRuby post said
they needed to delete the ‘Current’ symlink because there were
multiple versions of Ruby and thus duplicate Info.plists, but SDL
shouldn’t have this problem.)

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/

Eric – I tried removing all spaces from my app name. I named the bundle and target all “MidnightMansionHD” and rebuilt, verifying that “Executable File” and “Bundle Name” in the PList were both MidnightMansionHD. Same problem:

Package “com.actionsoft.midnightmansionepisode1”: Bundle at “MidnightMansionHD.app/Contents/Frameworks/SDL.framework” in Payload not declared in PackageInfo.

Attached is a sample of what I think the cleaned up SDL Info.plist
should look like.
I wonder if the creator code is the problem. I think all use ??? now.

I don’t have a Mac App Store membership/key so I can’t really
reproduce anything for you. I’ll make one other shot in the dark.
Maybe the bundle ID you register should use wildcards to allow the SDL
framework to match. So if you can create your signing key with
identifier , or change the SDL framework to com.actionsoft.libsdl and
make your key com.actionsoft.
, maybe this will pass the validation
process.

-Eric–
Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/
-------------- next part --------------
A non-text attachment was scrubbed…
Name: Info.plist
Type: application/octet-stream
Size: 704 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110724/bcdac3d4/attachment.obj

If you still can’t make this work, I recommend you use one of your DTS
incidents to get direct help from Apple. I wish I thought of this
sooner. I had two that expired last week that went to waste. I would
have used one of them for this.On 7/24/11, Eric Wing <@Eric_Wing> wrote:

Attached is a sample of what I think the cleaned up SDL Info.plist
should look like.
I wonder if the creator code is the problem. I think all use ??? now.

I don’t have a Mac App Store membership/key so I can’t really
reproduce anything for you. I’ll make one other shot in the dark.
Maybe the bundle ID you register should use wildcards to allow the SDL
framework to match. So if you can create your signing key with
identifier , or change the SDL framework to com.actionsoft.libsdl and
make your key com.actionsoft.
, maybe this will pass the validation
process.

-Eric

Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/


Beginning iPhone Games Development
http://playcontrol.net/iphonegamebook/