Messages

1

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 08, 2012, 06:22:31 pm »

Indeed I could modify cmake script to make it work for Xcode 4.3 however, this would be useless once cmake is updated.

Nope, I understand completely. I really just meant could I modify it, as I need to compile SFML for 10.6 compatibility and have already upgraded to 4.3.

Until CMake gets updated, it will have to suffice. Thanks again!

2

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 08, 2012, 06:05:46 pm »

Yep, cmake team is working on it. http://public.kitware.com/Bug/view.php?id=12621  :wink:

Awesome! In the meantime, will manually editing the CmakeLists.txt file fix the issue? It seems like if I just update the "CMAKE_OSX_SYSROOT" settings section to point to the new SDKs location, it should be okay.

Or am I misunderstanding how CMake works? I have really never dug much into editing CMake files...

3

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 08, 2012, 05:26:43 pm »

Crap... I just bought a new MacBook Pro, and had to update to Xcode 4.3 from the App Store. Turns out they moved everything around since 4.2, so the default location that CmakeLists.txt tells Cmake to search for the SDKs is no longer valid.

If anyone runs into this and is wondering, in Xcode 4.3, the SDKs are bundled into the the Xcode app itself at:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs

By default, the current CmakeLists.txt looks at the old 4.2 location, which is:

/SDKs

If you are trying to build SFML and you only have 4.3 installed, you will need to be sure to update the path to the SDKs if you want to build for 10.6 like I do...

Just a general FYI.

4

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 07, 2012, 07:21:26 pm »

I can't do anything about that because cmake and xcode's templates are not related at all (i.e., you will be able to download SFML 2.0 with its templates but without any cmake related material when it's released).

My hard drive apologizes for crashing and preventing me from having answered faster. Fortunately, Ceylo was there.  

Oh, no worries at all--I was definitely not complaining about your work. I appreciate the project templates 100%!

I just hate it when you go to a forum, find someone who was having your problem, and then find that the last post just says "Ok, I fixed it." And then they don't tell you what fixed it. So I just wanted to very clearly spell out what someone would need to do if they encounter this same issue in the future.

But yes, thank you very much for the templates!

5

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 06, 2012, 03:50:38 pm »

Yay, it looks like it is working! I just sent the "Hello SFML" demo project, and it worked for him, so I will send the actual project tonight to make sure that works as well. But it looks like everything is working now.

It seems you were correct that the issue was SFML being built with the wrong OSX SDK. When you fire up CMake with OSX/SFML, it defaults to using the 10.7 SDK, so you have to make sure to reset everything to 10.6.

Also worth noting: the Xcode project templates target 10.7 no matter what you do in CMake, so you have to be sure to update your project to target 10.6 before building the project.

If I have any more issues, I will update, but it looks like I am in the clear. Thanks again so much for your help--I would have gone insane trying to figure this out on my own!

6

General / The program can't start because libstdc++-6.dll is missing?

« on: March 06, 2012, 03:45:44 pm »

You will probably need to include libgcc_s_dw2-1.dll as well. Should be in the same folder as libstdc++-6.dll.

7

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 05, 2012, 08:51:46 pm »

SFML has been built with the wrong SDK (either because of one of your choices or because of the provided CMakeLists.txt file).

Ah, yes, that could very well be my error. I originally built SFML with the 10.7 SDK, and then re-built it yesterday with 10.6, but I can't help but wonder if some remnants of the 10.7 build remained. I will have to clean up all SFML on my system, and try starting from scratch. I will report back once I get a chance to do so.

Once again, thank you so much for helping me through this. I really appreciate it very much!

8

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 05, 2012, 06:27:47 pm »

Ok, well I tried what I mentioned before, and now I get back a different error message about libfreetype:

Code: [Select]

Process:         TestProject [200]
Path:            /Users/[User]/Desktop/TestProject.app/Contents/MacOS/TestProject
Identifier:      wediditgames.TestProject
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  launchd [94]

Date/Time:       2012-03-05 11:21:52.974 -0600
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          2431777 sec
Crashes Since Last Report:           56
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      75161EC6-C3F6-4605-8CC6-3543D09B9F3B

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Dyld Error Message:
  Library not loaded: /usr/X11/lib/libfreetype.6.dylib
  Referenced from: /Users/[User]/Desktop/TestProject.app/Contents/MacOS/../Frameworks/sfml-graphics.framework/Versions/2.0.0/sfml-graphics
  Reason: Incompatible library version: sfml-graphics requires version 14.0.0 or later, but libfreetype.6.dylib provides version 13.0.0

Binary Images:
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <63B47435-46CF-3D2D-F7F4-7FE77DEEFE06> /usr/lib/dyld

Model: MacBookPro6,2, BootROM MBP61.0057.B0C, 2 processors, Intel Core i7, 2.66 GHz, 8 GB, SMC 1.58f16
Graphics: NVIDIA GeForce GT 330M, NVIDIA GeForce GT 330M, PCIe, 512 MB
Graphics: Intel HD Graphics, Intel HD Graphics, Built-In, 288 MB
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x93), Broadcom BCM43xx 1.0 (5.10.131.42.4)
Bluetooth: Version 2.4.5f3, 2 service, 19 devices, 1 incoming serial ports
Network Service: AirPort, AirPort, en1
Serial ATA Device: Hitachi HTS545050B9SA02, 465.76 GB
Serial ATA Device: MATSHITADVD-R   UJ-898
USB Device: Hub, 0x0424  (SMSC), 0x2514, 0xfa100000 / 2
USB Device: Apple Internal Keyboard / Trackpad, 0x05ac  (Apple Inc.), 0x0236, 0xfa120000 / 5
USB Device: Internal Memory Card Reader, 0x05ac  (Apple Inc.), 0x8403, 0xfa130000 / 4
USB Device: BRCM2070 Hub, 0x0a5c  (Broadcom Corp.), 0x4500, 0xfa110000 / 3
USB Device: Bluetooth USB Host Controller, 0x05ac  (Apple Inc.), 0x8218, 0xfa113000 / 8
USB Device: Hub, 0x0424  (SMSC), 0x2514, 0xfd100000 / 2
USB Device: Built-in iSight, 0x05ac  (Apple Inc.), 0x8507, 0xfd110000 / 4
USB Device: IR Receiver, 0x05ac  (Apple Inc.), 0x8242, 0xfd120000 / 3

Is libfreetype something that is built-in to SFML, or is that a system library (maybe one that was updated in Lion)? Is this something I would need to check for in an installer, or something else I can just bundle with the .app? Thanks again for all your help!

9

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 05, 2012, 05:37:37 pm »

Hmm, okay. That all makes sense. Is there a specific setting in my Xcode project I need to change to make it look for frameworks instead? I definitely did not change anything from the default settings of the template project.

It seems like the following would be the area I should be looking at:



If I am reading this correctly, it is telling debug builds to look for .dylibs ("-d" suffix), but the -framework flag is not used anywhere. Does that mean I need to add "-framework" to the beginning of all of the compiler flags for the release builds, or am I misunderstanding this? (Or perhaps I should just set it up to copy the .dylibs over instead of the frameworks?)

Sorry if this seems like stuff I could solve through trial-and-error. The issue is that everything works fine on my end, but not on my artist's end, so I have to package and send him a build to get any feedback on the issue, so I am trying to minimize the number of times I do that to keep from driving him crazy.

Thanks again!


edit: oh crap, this is going to make me look like an idiot, but I think I may have found the issue, and I think it is what I mentioned above, that the linkers were looking for dylibs because of the "-l" flag. I just realized when you start a new SFML project from the template, there is a "Use Frameworks" checkbox that I must have unchecked. Sure enough, starting a project with that checked changes all of the "-l" flags to "-framework". I am going to send a new test to my artist and see if that fixes it. How embarrassing... =/

10

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 05, 2012, 02:19:40 am »

Ok, so I have some error message goodness:

Code: [Select]

Process:         asdf [1174]
Path:            /Users/[username]/Desktop/2-tests/Debug/asdf.app/Contents/MacOS/asdf
Identifier:      wediditgames.asdf
Version:         ??? (???)
Code Type:       X86-64 (Native)
Parent Process:  launchd [94]

Date/Time:       2012-03-04 19:03:45.040 -0600
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          2430874 sec
Crashes Since Last Report:           55
Per-App Crashes Since Last Report:   3
Anonymous UUID:                      75161EC6-C3F6-4605-8CC6-3543D09B9F3B

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  0

Dyld Error Message:
  Library not loaded: @executable_path/../Frameworks/libsfml-system-d.2.dylib
  Referenced from: /Users/[username]/Desktop/2-tests/Debug/asdf.app/Contents/MacOS/asdf
  Reason: image not found

Binary Images:
    0x7fff5fc00000 -     0x7fff5fc3bdef  dyld 132.1 (???) <63B47435-46CF-3D2D-F7F4-7FE77DEEFE06> /usr/lib/dyld


Yes, it is actually called 'asdf.' For testing reasons, I just sent him the SFML demo project, so 'asdf' was the natural name my left hand typed.

This is the Debug build, too. Not sure if that will make a difference, but it's clearly not finding the SFML System library. Neither Release nor Debug build ends up with the .dylib files in the build. I don't know if that means I am building it wrong or what--in both builds' 'Frameworks' folders, it just has all of the SFML libraries as .framework folders, but no .dylib versions. Do I just need to manually add the .dylib versions to the .app bundles, or did I miss a setting in Xcode?

To be honest, I have never been quite clear on the difference between .framework and .dylib libraries. Like I said, I am pretty new to developing for OSX. (Also, I guess the issue at this point is not necessarily deploying for older versions of OSX, but rather just making sure it is bundled properly.)

Does this help? Any advice you guys can provide is greatly appreciated. Thanks again!

11

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 04, 2012, 10:37:35 pm »

I personally do not have access to 10.6, so I am just kind of getting reports from the artist I work with. The error message is:

[The Application] cannot be opened because of a problem. Check with the developer to make sure " " works with this version of Mac OS X. You may need to reinstall the application. Be sure to install any available updates... etc.

Which sounds to me like I just need to use the 10.6 SDK instead of 10.7, but that did not seem to work--I looked through all of the options in the Xcode project, and changed as many as I code find to use the 10.6 SDK. Is there potentially anything else I need to change?

Thanks again for your help!

12

General / Deploying for older versions of OSX? (e.g. 10.6 and/or 10.5)

« on: March 04, 2012, 08:40:26 pm »

Hi guys, I have started working with SFML 2 on my OSX Lion machine, and I am having some issues. Admittedly, I am pretty new to development on OSX--I am really just used to Windows, where you just build it, throw the libraries in the same folder as the .exe file, and call it a day. OSX is proving to be a little more complicated, though.

Like I said, I am coding and building on Lion with Xcode 4.2. I built it for OSX using the instructions in the 4th post here:
http://www.sfml-dev.org/forum/viewtopic.php?t=6122&highlight=build+mac

Everything works fine when I am building and running on Lion, but it's not working on Snow Leopard, and I need to know what I need to change to make sure it builds and runs on at least Snow Leopard (Leopard would also be nice, but Snow Leopard is a MUST).

I have tried re-building SFML 2 with the 10.6 SDK instead of the 10.7 one, and I updated the Xcode template project to build with the 10.6 SDK as well, but it is still not running on 10.6.

Does anyone know what else I might need to change to get it running on 10.6? Is this more likely an issue with how I am building SFML, or how I am building the project itself? Sorry if this is a noob-ish question. As I mentioned, I am pretty new to Xcode and OSX deployment, so I really don't fully understand the whole process very well yet.

The end-user does not need to install any libraries, right? As far as I can tell, Xcode bundles all of the dependencies in with the .app file, but I could be wrong.

Any help would be greatly appreciated!

13

General discussions / New naming convention

« on: January 20, 2012, 03:32:34 pm »

Hi Laurent,

I registered this account after being a long-time lurker just to weigh in on this topic, so consider this one more vote in favor of camelCase function/method names. Just a personal preference, but it's the way I like it.

However, I would personally prefer if the "get/set/is" naming convention stayed. I really like just being able to type "get" in an IDE, and immediately being able to see all possible things you can... well... get from a class, all neatly in same place (and likewise with "set").

It's all pretty small potatoes, though. As long as the API stays awesome, I can adapt to whatever naming conventions you are most comfortable with.