September 2008 - Installer-dev

RE: Migration from VISE to PackageMaker
by Gu, Kevin 27 Sep '08

27 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: AckgHzpa9WJ7PkGES2GySkfOtxsdkgASrAvw Thread-topic: Migration from VISE to PackageMaker Hi Stéphane, Many thanks. Although I haven't found when the short language name will be incorrect, I will take your suggestion And besides this topic, would you please shed some light on other topics, because I am really a new user of Package Maker, and the user guide is not enough for me. Best Regards, Kevin Gu > -----Original Message----- > From: Stéphane Sudre [mailto:iceberg-dev@orange.fr] > Sent: 2008年9月27日 5:31 > To: Gu, Kevin > Cc: Installer-Dev mailing-list > Subject: Re: Migration from VISE to PackageMaker > > > On Sep 26, 2008, at 4:38 AM, Gu, Kevin wrote: > > > Hi all, > > > > > > > > Well, I have found the answer to the second question: Italiano is > > it; Nederlands is nl. > > > > That's right and wrong. > > Italiano should actually be Italian, > > There's a bug in Installer.app which means supports for short > language name is not 100% correct. It's safer to use complete name > when possible. > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: errors when building pmdoc files from command line
by Scott Amory 26 Sep '08

26 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Migration from VISE to PackageMaker
by Gu, Kevin 26 Sep '08

26 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Acke7VJLoKqbuY08QDOmUyMRGQ4IsAAkyQ2AAACdR9wAEsu+YA== Thread-topic: Migration from VISE to PackageMaker _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

errors when building pmdoc files from command line
by sandeep chaudhary 26 Sep '08

26 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=AAD8g5+yNk737gRFgDHDGGqjrFSGq6NquWCKh4cTLH+QarRgP3IjK/0/NWGUzjl3ZBs6QZnFvhDyoYqD+FLieyedJ67wyv6yBMazeYYgBSkSYWyPQwUYsBZ7GiNs9W86bnb3WFf1Q7DJnUZr8WRUQm+dopuh26jy/SUM/UED9Sc=; _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Migration from VISE to PackageMaker
by Gignac, Jason (HAS-SAT) 26 Sep '08

26 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Acke7VJLoKqbuY08QDOmUyMRGQ4IsAAkyQ2AAACdR9w= Thread-topic: Migration from VISE to PackageMaker _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: Migration from VISE to PackageMaker
by Gu, Kevin 26 Sep '08

26 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Acke7VJLoKqbuY08QDOmUyMRGQ4IsAAkyQ2A Thread-topic: Migration from VISE to PackageMaker _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: dylib inter-dependencies, install_name_tool and @loader_path
by Lisa Weimer 25 Sep '08

25 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Thread-index: Acke84l+EibmL8XiRLOqObVwNucjRwAYI0Bw Thread-topic: dylib inter-dependencies, install_name_tool and @loader_path Hey Nicolas, Yup, should work--evfen with your dylibs in a relative location, as long as you remember to change the dependency path in the things that need it to the same path. It should expand it properly at runtime, no matter where your user relocates your app. Only way to for sure know is to test it on your app :) In this case one you change everything and package it up to distribute, it will work the same. I do think there is slightly different linking options in leopard then were in tiger, at least through the xcode linker bits, so if you are hooking this up in xcode be sure to do some reading. But just using install_name_tool to change things, at least in my experience it just works-- I haven't had any bugs assigned back to me that trace back to a linking problem that I have fixed on an app for OS X. Lisa -----Original Message----- From: installer-dev-bounces+lisaweimer=smarttech.com(a)lists.apple.com [mailto:installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com] On Behalf Of Nicolas.Castagne(a)imag.fr Sent: Thursday, September 25, 2008 3:33 AM To: installer-dev(a)lists.apple.com Subject: RE: dylib inter-dependencies, install_name_tool and @loader_path Hi Lisa, > I don't know if this will help at all, but hopefully it doesn't cause > more confusion for you. Less confusion, and great help indeed :/ Thanks for your answer. Everything seems OK now. Indeed, the problem was caused by a dylib loaded at run time : my executable search path loaded the system-scope library. One question remains... > id in install name tool allows you to change the install_name. You can > read more about install_name in the ld man page. You can set the > install_name in the Xcode linker options, or you can use > install_name_tool to change this setting. Install_name (id) is means > this: things linked against that library will record that path as the > way dyld should locate that library. Well, since my dylibs are in a relative location, I've used for them the id: @loader_path/MyDyLib.dylib Would you think that's OK? Will @loader_path be taken into account, and changed to the actual absolute path of the loaded library? As far as I checked, that's OK. But... Who knows... Best- Nicolas > Hi Nicolas, > > I've just finished remapping a bunch of frameworks and dylibs for my > company's applications, so I will take a crack at answering this. > > It sounds like your dylib was not relocated properly if it loaded the > global one first. If you properly relocate things, then the system will > always use your copy of whatever was relocated. > > I don't know what happens if the copy you want to use doesn't > exist--that is, I can't confirm that it searches the global system path > after trying your path, but based on my linux experience, it wouldn't > surprise me if that was the default behaviour. (I think if you want it > to search a specific series of paths, you need to set this behaviour in > xcode at linking time using -rpath. I don't know much about doing things > in xcode at linking time so I can't help you there.) > > id in install name tool allows you to change the install_name. You can > read more about install_name in the ld man page. You can set the > install_name in the Xcode linker options, or you can use > install_name_tool to change this setting. Install_name (id) is means > this: things linked against that library will record that path as the > way dyld should locate that library. > > @loader_path, as far as I understand it means this: at run time dyld > replaces @loader_path with the path to the Mach-O binary that loaded it > (an executable or another shared library of some sort). Unlike > @executable_path which only refers to the main executable. > > When you changed the ids and references did you use this procedure? > Use install name tool > 1. change the id of a.framework (no longer is the system copy) > 2. change the id of b.framework (no longer is the system copy) > 3. in a.framework, change the reference to look for your copy of > b.framework > (Install_name_tool -change) > 4. in your exececutable change the references to look for your copies of > a.framework and b.framework. (Install_name_tool -change) > > You can check all of your work with otool -L, see where and how things > are referring to each other. > > So for your app and libs, the first thing I would do is run otool > against them all, and verify that things are referring to the right > things, and also verify the places they are looking actually exist. > > I've read before that install_name_tool only works if the new > install_name (id) is no longer than the old one. But I've never run into > this limitation yet, lucky me. > > I don't know if this will help at all, but hopefully it doesn't cause > more confusion for you. Other mail lists that might help are xcode > development mail lists. > > Best, > Lisa Weimer > > -----Original Message----- > From: installer-dev-bounces+lisaweimer=smarttech.com(a)lists.apple.com > [mailto:installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com] > On Behalf Of Nicolas.Castagne(a)imag.fr > Sent: Wednesday, September 24, 2008 7:44 AM > To: installer-dev(a)lists.apple.com > Subject: Re: dylib inter-dependencies, install_name_tool and > @loader_path > > Hi again, > > Indeed, one of the problems was caused by a dynamically dylib loaded at > run time (a plugin). The plugin was searched in a global system scope, > instead > of being searched inside my distribution. > > Hence, as far as checked, using @loader_path/**relative_path_to_B** > inside a > .dylib A to refer to a dependent library B behave as following: > > 1- if path_of_A/**relative_path_to_B** is existing dylib B is, this > version of B is loaded > > 2- if path_of_A/**relative_path_to_B** is NOT can existing dylib B, then > B > is searched in the global system path. > > Is this correct? > > Anyhow, my first question is still valid: >> install_name_tool allows changing the "id" of a dynamic library, with > -id. >> But What Does "id" Mean ? >> And what is the impact of the lib's "id" on loading? >> I've browsed the doc and the Net for long, but did not find any clear >> info... > > > Thanks, > Nicolas > > > >> Hi folks, >> >> I am trying to make my applications distribution for mac OSX.4 and > X.5, >> but >> have a couple of problem with the dynamic loading of libraries. >> >> >> My first question is: >> install_name_tool allows changing the "id" of a dynamic library, with > -id. >> But What Does "id" Mean ? >> And what is the impact of the lib's "id" on loading? >> I've browsed the doc and the Net for long, but did not find any clear >> info... >> >> >> My second question is: >> What does @loader_path means exactly ? >> I did not find any clear info on this, and basically, the observed >> behavior does not match what the doc (apparently) says. >> >> >> >> Let's now get into a bit more details. >> >> >> My distribution contains various executables, both bundled apps and >> command-line, that rely on various interdependent libraries. The > distrib >> looks like: >> distrib >> |_ bin >> |_ cmdlineexecutable >> |_ application.app >> |_ lib >> |_ A.framework >> |_ B.framework >> where both executable depend on A AND B, and where A depends on B. >> >> >> Since the executables are NOT on the same level in the distribution > tree, >> using @executable_path inside a library to refer to another library is > NOT >> possible. >> >> >> I guess I have to use @loader_path: the executable would refer to a >> libraries using @executable_path, and the libraries would refer to > each >> others using @loader_path >> >> >> According to the doc: >>> Library-relative location. To specify a file path relative to >>> the location of the library itself, >>> place the @loader_path macro at the beginning of the pathname. >> >> However, when using @loader_path, and when the framework is installed > BOTH >> inside my distribution AND in a system-searchable location (eg: >> /Library/Framework) then BOTH versions of a library are loaded when >> launching the app. >> >> >> I guess that: >> - the executable, that depends on frameworks A and B refered by using >> @executable_path, loads the executable-relative versions of the > frameworks >> A and B >> - framework A, that depends on framework B referred by using > @loader_path, >> loads the version of B which is located in /Library/Frameworks >> >> >> Hence, @loader_path would NOT refer to the currently-loaded library >> path... And the doc would lie :/ >> >> >> I would appreciate any help on this situation. >> >> Thanks much for your attention, >> best- >> Nicolas >> >> PS: First message on this list. I hope it I picked the correct list. > Sorry >> if I was wrong :/ >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/installer-dev/lisaweimer%40smartt > ech.com > > This email sent to lisaweimer(a)smarttech.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/installer-dev/nicolas.castagne%40 imag.fr > > This email sent to nicolas.castagne(a)imag.fr > _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/lisaweimer%40smartt ech.com This email sent to lisaweimer(a)smarttech.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: compile .pmdoc file with command line
by Ulf Dunkel 25 Sep '08

25 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Organization: invers Software & DSD.net User-agent: Thunderbird 2.0.0.17pre (Windows/20080925) Hi Sandeep. I wonder if the \ in your fspec is an issue. HTH, UlfDunkel _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… "ERROR: The specified document is invalid: /Users/abhinavkumar/Desktop/Sandeep/Installers/Radium\Glow/ProjectFiles/AfterEffectsCS3.pmdoc" This email sent to site_archiver(a)lists.apple.com

1 0

compile .pmdoc file with command line
by sandeep chaudhary 25 Sep '08

25 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=oE/WhTdE44Fp1fwn4F+Ug+2FJ1mj3cGMY0gFTkkQeSAoU2kcj440QfUtZlHXn1xQbRAdgjMehDqsFuMIWblZgQ/xR1ndSV/ZMG677eT9MoI5u74J6OqVhL6YKNxNBZIE5eOqwIm74iMvrQvZIJvQmAuEjHRpdkBcnziKhyk4R/0=; Hi all , I am creating a .pmdoc file and want to compile it from command line. i have write a command in shell script to compile it. Below is the command- /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker -d "$AfterEffectsCS3" -o "$ç" where i have used two variables AfterEffectsCS3 and AfterEffectsCS3pkg. AfterEffectsCS3 contains the .pmdoc file and AfterEffectsCS3pkg is the meta package file which will create after compilation of .pmdoc file. But i am getting the following error- "ERROR: The specified document is invalid: /Users/abhinavkumar/Desktop/Sandeep/Installers/Radium\Glow/ProjectFiles/AfterEffectsCS3.pmdoc" what i am doing wrong. please help me on this. Thanks -sandeep Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/ _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

RE: dylib inter-dependencies, install_name_tool and @loader_path
by Nicolas.Castagne＠imag.fr 25 Sep '08

25 Sep '08

site_archiver(a)lists.apple.com Delivered-To: installer-dev(a)lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.9a Hi Lisa, > I don't know if this will help at all, but hopefully it doesn't cause > more confusion for you. Less confusion, and great help indeed :/ Thanks for your answer. Everything seems OK now. Indeed, the problem was caused by a dylib loaded at run time : my executable search path loaded the system-scope library. One question remains... > id in install name tool allows you to change the install_name. You can > read more about install_name in the ld man page. You can set the > install_name in the Xcode linker options, or you can use > install_name_tool to change this setting. Install_name (id) is means > this: things linked against that library will record that path as the > way dyld should locate that library. Well, since my dylibs are in a relative location, I've used for them the id: @loader_path/MyDyLib.dylib Would you think that's OK? Will @loader_path be taken into account, and changed to the actual absolute path of the loaded library? As far as I checked, that's OK. But... Who knows... Best- Nicolas > Hi Nicolas, > > I've just finished remapping a bunch of frameworks and dylibs for my > company's applications, so I will take a crack at answering this. > > It sounds like your dylib was not relocated properly if it loaded the > global one first. If you properly relocate things, then the system will > always use your copy of whatever was relocated. > > I don't know what happens if the copy you want to use doesn't > exist--that is, I can't confirm that it searches the global system path > after trying your path, but based on my linux experience, it wouldn't > surprise me if that was the default behaviour. (I think if you want it > to search a specific series of paths, you need to set this behaviour in > xcode at linking time using -rpath. I don't know much about doing things > in xcode at linking time so I can't help you there.) > > id in install name tool allows you to change the install_name. You can > read more about install_name in the ld man page. You can set the > install_name in the Xcode linker options, or you can use > install_name_tool to change this setting. Install_name (id) is means > this: things linked against that library will record that path as the > way dyld should locate that library. > > @loader_path, as far as I understand it means this: at run time dyld > replaces @loader_path with the path to the Mach-O binary that loaded it > (an executable or another shared library of some sort). Unlike > @executable_path which only refers to the main executable. > > When you changed the ids and references did you use this procedure? > Use install name tool > 1. change the id of a.framework (no longer is the system copy) > 2. change the id of b.framework (no longer is the system copy) > 3. in a.framework, change the reference to look for your copy of > b.framework > (Install_name_tool -change) > 4. in your exececutable change the references to look for your copies of > a.framework and b.framework. (Install_name_tool -change) > > You can check all of your work with otool -L, see where and how things > are referring to each other. > > So for your app and libs, the first thing I would do is run otool > against them all, and verify that things are referring to the right > things, and also verify the places they are looking actually exist. > > I've read before that install_name_tool only works if the new > install_name (id) is no longer than the old one. But I've never run into > this limitation yet, lucky me. > > I don't know if this will help at all, but hopefully it doesn't cause > more confusion for you. Other mail lists that might help are xcode > development mail lists. > > Best, > Lisa Weimer > > -----Original Message----- > From: installer-dev-bounces+lisaweimer=smarttech.com(a)lists.apple.com > [mailto:installer-dev-bounces+lisaweimer=smarttech.com@lists.apple.com] > On Behalf Of Nicolas.Castagne(a)imag.fr > Sent: Wednesday, September 24, 2008 7:44 AM > To: installer-dev(a)lists.apple.com > Subject: Re: dylib inter-dependencies, install_name_tool and > @loader_path > > Hi again, > > Indeed, one of the problems was caused by a dynamically dylib loaded at > run time (a plugin). The plugin was searched in a global system scope, > instead > of being searched inside my distribution. > > Hence, as far as checked, using @loader_path/**relative_path_to_B** > inside a > .dylib A to refer to a dependent library B behave as following: > > 1- if path_of_A/**relative_path_to_B** is existing dylib B is, this > version of B is loaded > > 2- if path_of_A/**relative_path_to_B** is NOT can existing dylib B, then > B > is searched in the global system path. > > Is this correct? > > Anyhow, my first question is still valid: >> install_name_tool allows changing the "id" of a dynamic library, with > -id. >> But What Does "id" Mean ? >> And what is the impact of the lib's "id" on loading? >> I've browsed the doc and the Net for long, but did not find any clear >> info... > > > Thanks, > Nicolas > > > >> Hi folks, >> >> I am trying to make my applications distribution for mac OSX.4 and > X.5, >> but >> have a couple of problem with the dynamic loading of libraries. >> >> >> My first question is: >> install_name_tool allows changing the "id" of a dynamic library, with > -id. >> But What Does "id" Mean ? >> And what is the impact of the lib's "id" on loading? >> I've browsed the doc and the Net for long, but did not find any clear >> info... >> >> >> My second question is: >> What does @loader_path means exactly ? >> I did not find any clear info on this, and basically, the observed >> behavior does not match what the doc (apparently) says. >> >> >> >> Let's now get into a bit more details. >> >> >> My distribution contains various executables, both bundled apps and >> command-line, that rely on various interdependent libraries. The > distrib >> looks like: >> distrib >> |_ bin >> |_ cmdlineexecutable >> |_ application.app >> |_ lib >> |_ A.framework >> |_ B.framework >> where both executable depend on A AND B, and where A depends on B. >> >> >> Since the executables are NOT on the same level in the distribution > tree, >> using @executable_path inside a library to refer to another library is > NOT >> possible. >> >> >> I guess I have to use @loader_path: the executable would refer to a >> libraries using @executable_path, and the libraries would refer to > each >> others using @loader_path >> >> >> According to the doc: >>> Library-relative location. To specify a file path relative to >>> the location of the library itself, >>> place the @loader_path macro at the beginning of the pathname. >> >> However, when using @loader_path, and when the framework is installed > BOTH >> inside my distribution AND in a system-searchable location (eg: >> /Library/Framework) then BOTH versions of a library are loaded when >> launching the app. >> >> >> I guess that: >> - the executable, that depends on frameworks A and B refered by using >> @executable_path, loads the executable-relative versions of the > frameworks >> A and B >> - framework A, that depends on framework B referred by using > @loader_path, >> loads the version of B which is located in /Library/Frameworks >> >> >> Hence, @loader_path would NOT refer to the currently-loaded library >> path... And the doc would lie :/ >> >> >> I would appreciate any help on this situation. >> >> Thanks much for your attention, >> best- >> Nicolas >> >> PS: First message on this list. I hope it I picked the correct list. > Sorry >> if I was wrong :/ >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/installer-dev/lisaweimer%40smartt > ech.com > > This email sent to lisaweimer(a)smarttech.com > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Installer-dev mailing list (Installer-dev(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/installer-dev/nicolas.castagne%40ima… > > This email sent to nicolas.castagne(a)imag.fr > _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0