Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OpenAL & prebinding warnings

At 10:37 PM -0600 9/14/02, Chad Armstrong wrote:
These are the frameworks I've included: libstdc++.a,
ApplicationServices, CoreServices, AppKit, GLUT, OpenGL, OpenAL. Any
idea how I can work around these warnings to fix the prebinding problems?

It sounds like the OpenAL library isn't properly prebound.

Mach-O is a broken and archaic executable format, which unlike modern formats like PEF requires you to specify the default address a framework (shared library) is to be loaded at. This address is halfway important, because it can't overlap the default address of any other frameworks or executables in your project if you want the linker to generate prebinding information. It's only halfway important, because it can essentially be random; the operating system (as of 10.2) has a fix_prebindings daemon that will adjust installed frameworks and applications not to conflict and to be entirely up to date.

So in the Project Builder project that builds OpenAL.framework, you need to specify the default address OpenAL.framework should be loaded at by specifying a -seg1addr value in the "Other Mach-O Linker Flags" portion of the Linker Settings panel for your framework's target. There are some restrictions on the addresses you can use with -seg1addr; check the archives at <http://cocoa.mamasam.com/> for more information. (At least, I think that's where I learned about this stuff. There might also be information in man pages or in Project Builder's documentation. Somewhere.)

I also notice that in your link error listing that OpenAL.framework is at /System/Library/Frameworks/OpenAL.framework.

*** Don't do that. ***

/System belongs to Apple. Period. Except for kernel extensions, *no* non-Apple software should *ever* be installed in /System. (And personally, I don't think non-Apple kernel extensions should be there either. They should be in /Library/Extensions; I don't *care* how much more work it is for the kernel extension loader to search two folders.)

And it's not like you can just compile your application with OpenAL in /System/Library/Frameworks and then distribute it with OpenAL being placed in /Library/Frameworks. This is because, again, Mach-O is a broken and archaic executable format, which unlike modern formats like PEF actually stores the FULL PATH of the frameworks (shared libraries) that an executable links against within the executable. This is supremely stupid in the 21st century, but that's how it works.

I really wish Mach-O wasn't such complete garbage. It would have made my life a lot easier when putting together BDControl, BDRuleEngine, and BDRuleEditor. And I'm positive it would make a large number of other developers' lives easier too.

-- Chris

--
Chris Hanson | Email: email@hidden
bDistributed.com, Inc. | Phone: +1-847-372-3955
Making Business Distributed | Fax: +1-847-589-3738
http://bdistributed.com/ | Personal Email: email@hidden
_______________________________________________
mac-games-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/mac-games-dev
Do not post admin requests to the list. They will be ignored.
References: 
 >OpenAL & prebinding warnings (From: Chad Armstrong <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.