Re: Mplayer Variant Help
Thanks for the detailed response. I don't know enough about compiling to come up with a universal build, so I guess I'll stick with an intel only build. If I may, I have a follow up on the platform constraints. So these constraints have nothing to do with what systems the compiled binaries will run on. Is that right? I seem to recall reading somewhere that macport builds will run on 10.4 and higher if I install with 10.5. Looking at the macports guide, it looks like if there is no configure.compiler line in the port file and if I'm using 10.5.6, then the default is gcc-4.0 which will result in 10.4 and 10.5 friendly binaries. Am understanding that correctly? Thanks. On May 13, 2009, at 7:38 PM, Ryan Schmidt wrote: On May 13, 2009, at 12:25, EmmGunn wrote: I'm looking at the different variants for mplayer and most of them are self explanatory, but I have a couple of questions. I noticed this in the port file: 83 # configure is not autoconf 84 universal_variant no which I took to mean that a universal variant is not available, That's correct. Because mplayer does not use a standard autoconf configure script, the standard universal variant does not work with it. If someone wanted to invest some time in figuring out how to make mplayer compile universal, it could probably be done by writing a custom universal variant for that port. but then I see a binary_codecs variant which has something about powerpc and i386. What does this do exactly? Is this something equivalent to a universal variant? I was hoping to compile a universal build of mplayer. Sorry, the port says universal_variant no, which means someone tried to build a universal binary and found that it failed, and added this to the portfile to save you the trouble. If you really want a universal binary, you will have to write a custom universal variant for this port. If you do, please contribute it back to us so that we can put it in the portfile. Also, just out of curiosity, what are the darwin and darwin_8 variants. I couldn't find anything about them either. Thanks in advance for any help. These are platform variants. If they are present in a portfile, MacPorts automatically selects them on the appropriate platform. darwin variants are selected on operating systems based on Darwin, including Mac OS X. darwin_8 is selected on Darwin 8.x operating systems, such as Mac OS X 10.4.x. Darwin 9.x would be Mac OS X 10.5.x, and so on. darwin_i386 is selected if you're running Darwin (or Mac OS X) on an Intel processor. darwin_powerpc is selected if you're running Darwin (or Mac OS X) on a PowerPC processor. You never select these variants manually; MacPorts does it for you if necessary. Ports use these variants if they need different instructions to build correctly in different kinds of environments. The description of the binary_codecs variant says Enable platform- specific binary codecs. Most ports in MacPorts are compiled from source but sometimes bits are only available as pre-compiled binaries, as is apparently the case for the codecs this variant wants to enable. This variant seems to be designed to download one file for PowerPC computers and a different file for Intel computers, and then install their contents. However, I don't believe the variant functions as intended. It checks whether variants darwin_i386 or darwin_powerpc are set. Since the port does not declare any variants by those names, those variants are never set, hence the binary_codecs variant never does anything. This is a bug in the portfile. It looks like when the binary_codecs variant was set up in r20652, darwin_i386 and darwin_powerpc variants did exist in the port, but they were subsequently removed without considering the effect that would have on the binary_codecs variant. I fixed this bug just now, but now the variant produces an error. Since I'm not an MPlayer expert I filed a ticket for this problem: http://trac.macports.org/ticket/19619 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mplayer Variant Help
I couldn't get the mplayer to build and so tried mplayer-devel which worked like a charm. On May 13, 2009, at 8:35 PM, Eric Cronin wrote: On May 13, 2009, at 10:38 PM, Ryan Schmidt wrote: On May 13, 2009, at 12:25, EmmGunn wrote: I'm looking at the different variants for mplayer and most of them are self explanatory, but I have a couple of questions. I noticed this in the port file: 83 # configure is not autoconf 84 universal_variant no which I took to mean that a universal variant is not available, That's correct. Because mplayer does not use a standard autoconf configure script, the standard universal variant does not work with it. If someone wanted to invest some time in figuring out how to make mplayer compile universal, it could probably be done by writing a custom universal variant for that port. but then I see a binary_codecs variant which has something about powerpc and i386. What does this do exactly? Is this something equivalent to a universal variant? I was hoping to compile a universal build of mplayer. Sorry, the port says universal_variant no, which means someone tried to build a universal binary and found that it failed, and added this to the portfile to save you the trouble. If you really want a universal binary, you will have to write a custom universal variant for this port. If you do, please contribute it back to us so that we can put it in the portfile. If someone is interested in tackling the universal build they may want to contact Mo Haque and see if the scripts he uses to update http://haque.net/software/mplayer/mplayerosx/builds/ are useful in manually setting up the crosscompile environment. Also, I'm not sure what the state of the new port is, but if mplayer- devel builds currently I would strongly recommend it over the MPlayer port since upstream stopped rolling full releases over 2 years ago and MPlayer hasn't been updated other than to fix build issues since then. Thanks, Eric ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qucs build error
14 maj 2009 kl. 05.08 skrev Ryan Schmidt: On May 13, 2009, at 08:25, Bjarne Bäckström wrote: On OS X 10.4.11 (intel) with a freshly installed MacPorts: [...] /usr/bin/g++-4.0 -O2 -pipe -fno-exceptions -fno-check-new -L/opt/ local/lib -o qucs -L/lib[...] Indeed, there should not be any directory /lib. I wonder why qucs is trying to look there. Found the problem earlier in the build report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Seems that it's rooting around where it has no business to do... So, I removed /sw/* from PATH, and tried to rebuild qucs. MacMini:~ bjarne$ echo $PATH /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin Still same report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib So, I ran 'uninstall -f installed' and rebuilt everything. Still same problem: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Now I'm wondering, where does it get /sw from? ;-) -- Regards, /Bjarne. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mplayer Variant Help
On 2009-5-15 02:20, EmmGunn wrote: If I may, I have a follow up on the platform constraints. So these constraints have nothing to do with what systems the compiled binaries will run on. Is that right? I seem to recall reading somewhere that macport builds will run on 10.4 and higher if I install with 10.5. That's not true in general. Platform variants contain code specific both to building on the corresponding platform and to running on it. MacPorts does not currently offer a way to build on one platform and target another. Running Leopard-built binaries on Tiger may succeed in *some* cases if you change universal_target to 10.4 and universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk. But any time there is a darwin_8 and/or darwin_9 variant, MP will select the one matching the build machine, which will generally cause problems. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mplayer Variant Help
Sorry for being so dense, but what happens when your installing using system 10.5 and there is a darwin_8 variant but no darwin_9 variant? Will the darwin_8 be used and the result work on 10.4, but then be iffy on 10.5? This is the mplayer-devel port file. On May 14, 2009, at 10:35 AM, Joshua Root wrote: On 2009-5-15 02:20, EmmGunn wrote: If I may, I have a follow up on the platform constraints. So these constraints have nothing to do with what systems the compiled binaries will run on. Is that right? I seem to recall reading somewhere that macport builds will run on 10.4 and higher if I install with 10.5. That's not true in general. Platform variants contain code specific both to building on the corresponding platform and to running on it. MacPorts does not currently offer a way to build on one platform and target another. Running Leopard-built binaries on Tiger may succeed in *some* cases if you change universal_target to 10.4 and universal_sysroot to /Developer/SDKs/MacOSX10.4u.sdk. But any time there is a darwin_8 and/or darwin_9 variant, MP will select the one matching the build machine, which will generally cause problems. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mplayer Variant Help
On 2009-5-15 04:28, EmmGunn wrote: Sorry for being so dense, but what happens when your installing using system 10.5 and there is a darwin_8 variant but no darwin_9 variant? Will the darwin_8 be used and the result work on 10.4, but then be iffy on 10.5? This is the mplayer-devel port file. Nope, darwin_8 variants are only selected on darwin 8 (Tiger). Something built on Tiger and deployed on Leopard has a far better chance of working than the other way round, BTW. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qucs build error
On May 14, 2009, at 12:21, Bjarne Bäckström wrote: 14 maj 2009 kl. 05.08 skrev Ryan Schmidt: On May 13, 2009, at 08:25, Bjarne Bäckström wrote: On OS X 10.4.11 (intel) with a freshly installed MacPorts: [...] /usr/bin/g++-4.0 -O2 -pipe -fno-exceptions -fno-check-new -L/ opt/local/lib -o qucs -L/lib[...] Indeed, there should not be any directory /lib. I wonder why qucs is trying to look there. Found the problem earlier in the build report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Seems that it's rooting around where it has no business to do... So, I removed /sw/* from PATH, and tried to rebuild qucs. MacMini:~ bjarne$ echo $PATH /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin MacPorts does not use your PATH while building. It uses its own path setup, specifically to avoid problems that might be caused by other locations in your path. Still same report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib So, I ran 'uninstall -f installed' and rebuilt everything. Still same problem: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Now I'm wondering, where does it get /sw from? ;-) The qucs configure script explicitly mentions /sw. We could attempt to patch the configure script to remove that reference. However, it is not supported to have both MacPorts and Fink installed at the same time, and you may run into similar issues with other ports. My recommendation is to remove Fink, or at least rename /sw to something else anytime you want to use MacPorts, because it can interfere like this. Similarly, some software, including qucs, will look at /usr/local for dependencies. Therefore, it is unsupported to have anything in /usr/ local while using MacPorts. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qucs build error - Solved (sort of)
14 maj 2009 kl. 19.21 skrev Bjarne Bäckström: 14 maj 2009 kl. 05.08 skrev Ryan Schmidt: On May 13, 2009, at 08:25, Bjarne Bäckström wrote: On OS X 10.4.11 (intel) with a freshly installed MacPorts: [...] /usr/bin/g++-4.0 -O2 -pipe -fno-exceptions -fno-check-new -L/ opt/local/lib -o qucs -L/lib[...] Indeed, there should not be any directory /lib. I wonder why qucs is trying to look there. Found the problem earlier in the build report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Seems that it's rooting around where it has no business to do... So, I removed /sw/* from PATH, and tried to rebuild qucs. MacMini:~ bjarne$ echo $PATH /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin Still same report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib So, I ran 'uninstall -f installed' and rebuilt everything. Still same problem: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Now I'm wondering, where does it get /sw from? ;-) OK, temporarily renaming /sw made qucs and its dependencies build fine. Question is, why hasn't this been a problem with earlier versions of qucs (or other ports)? -- Regards, /Bjarne. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qucs build error
14 maj 2009 kl. 23.53 skrev Ryan Schmidt: On May 14, 2009, at 12:21, Bjarne Bäckström wrote: 14 maj 2009 kl. 05.08 skrev Ryan Schmidt: On May 13, 2009, at 08:25, Bjarne Bäckström wrote: On OS X 10.4.11 (intel) with a freshly installed MacPorts: [...] /usr/bin/g++-4.0 -O2 -pipe -fno-exceptions -fno-check-new -L/ opt/local/lib -o qucs -L/lib[...] Indeed, there should not be any directory /lib. I wonder why qucs is trying to look there. Found the problem earlier in the build report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Seems that it's rooting around where it has no business to do... So, I removed /sw/* from PATH, and tried to rebuild qucs. MacMini:~ bjarne$ echo $PATH /opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin MacPorts does not use your PATH while building. It uses its own path setup, specifically to avoid problems that might be caused by other locations in your path. Still same report: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib So, I ran 'uninstall -f installed' and rebuilt everything. Still same problem: checking for Qt headers... found in /sw/include/qt checking for Qt... 3 (multi-threaded) checking for Qt library... found in /lib Now I'm wondering, where does it get /sw from? ;-) The qucs configure script explicitly mentions /sw. We could attempt to patch the configure script to remove that reference. However, it is not supported to have both MacPorts and Fink installed at the same time, and you may run into similar issues with other ports. My recommendation is to remove Fink, or at least rename /sw to something else anytime you want to use MacPorts, because it can interfere like this. Similarly, some software, including qucs, will look at /usr/local for dependencies. Therefore, it is unsupported to have anything in / usr/local while using MacPorts. Heh, got this mail immediately after posting... Well, removing Fink is out of the question, among other things because (for example; it goes both ways): MacMini:~ bjarne$ fink list | grep avr i avr-binutils2.19-1 GNU binutils for ATMEL AVR micro controllers i avr-gcc 4.2.0-2 GNU GCC for ATMEL AVR micro controllers i avr-libc1.6.5-2 AVR LIBC for GNU GCC GNU binutils i avrdude 5.5-1 Atmel AVR Microcontrollers Programmer MacMini:~ bjarne$ port list | grep avr avr-binutils @2.16.1 cross/avr-binutils avr-gcc@4.0.2 cross/avr-gcc avr-gdb@6.7.1 cross/avr-gdb avr-libc @1.6.1 cross/avr-libc avrdude@5.5cross/avrdude Thanks for your explanation! -- Regards, /Bjarne. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qucs build error
On May 14, 2009, at 17:10, Bjarne Bäckström wrote: Heh, got this mail immediately after posting... Well, removing Fink is out of the question, among other things because (for example; it goes both ways): MacMini:~ bjarne$ fink list | grep avr i avr-binutils2.19-1 GNU binutils for ATMEL AVR micro controllers i avr-gcc 4.2.0-2 GNU GCC for ATMEL AVR micro controllers i avr-libc1.6.5-2 AVR LIBC for GNU GCC GNU binutils i avrdude 5.5-1 Atmel AVR Microcontrollers Programmer MacMini:~ bjarne$ port list | grep avr avr-binutils @2.16.1 cross/avr-binutils avr-gcc@4.0.2 cross/avr-gcc avr-gdb@6.7.1 cross/avr-gdb avr-libc @1.6.1 cross/avr-libc avrdude@5.5cross/avrdude Thanks for your explanation! So you're saying we need to update the versions of some of our ports in MacPorts? That can certainly be arranged. :) Could you file tickets for the ports that need updates? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: qucs build error - Solved (sort of)
On May 14, 2009, at 16:59, Bjarne Bäckström wrote: Now I'm wondering, where does it get /sw from? ;-) OK, temporarily renaming /sw made qucs and its dependencies build fine. Question is, why hasn't this been a problem with earlier versions of qucs (or other ports)? I checked the previous version of qucs, 0.0.13, and it also explicitly mentions /sw in its configure script. So maybe this hasn't been a problem for you before because you did not have qt3 installed within Fink before. As to other ports, most of them probably do not explicitly mention / sw in their configure scripts. I'm sure it's a tricky situation for software developers: if they do add paths like /sw and /opt/local to their configure scripts, they make it easy for people to install their software manually and get dependencies from a package manager. However, by doing this, they make it more difficult to add their software to that package manager... ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
What is the preferred or recommended gcc version?
This one is not in the FAQ, yet, so here we go. Is there a general consensus, for the majority of ports without any specific build dependency, on which version of gcc is preferred or recommended for MacPorts? The following gcc variants are available: [ dwe...@x ~ ]$ gcc_select -l Available versions: gcc40 mp-gcc42 mp-gcc43 mp-gcc44 [ dwe...@x ~ ]$ ls -l /opt/local/bin/gcc* | sed -e 's/.*[0-9] \/opt/\/opt/' /opt/local/bin/gcc - /usr/bin/gcc-4.0* /opt/local/bin/gcc-apple-4.2 - /opt/local/lib/apple-gcc42/bin/gcc-apple-4.2* /opt/local/bin/gcc-mp-4.2* /opt/local/bin/gcc-mp-4.3* /opt/local/bin/gcc-mp-4.4* /opt/local/bin/gcc_select* /opt/local/bin/gccbug-mp-4.2* /opt/local/bin/gccbug-mp-4.3* /opt/local/bin/gccbug-mp-4.4* /opt/local/bin/gccxml* /opt/local/bin/gccxml_cc1plus* [ dwe...@x ~ ]$ ls -l /opt/local/bin/g++* | sed -e 's/.*[0-9] \/opt/\/opt/' /opt/local/bin/g++ - /usr/bin/bin/g++-4.0 /opt/local/bin/g++-mp-4.2* /opt/local/bin/g++-mp-4.3* /opt/local/bin/g++-mp-4.4* Take care, Darren ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What is the preferred or recommended gcc version?
On 2009-5-15 10:00, Darren Weber wrote: This one is not in the FAQ, yet, so here we go. Is there a general consensus, for the majority of ports without any specific build dependency, on which version of gcc is preferred or recommended for MacPorts? The one that is in the configure.cc variable. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What is the preferred or recommended gcc version?
On 2009-5-15 10:09, Joshua Root wrote: On 2009-5-15 10:00, Darren Weber wrote: This one is not in the FAQ, yet, so here we go. Is there a general consensus, for the majority of ports without any specific build dependency, on which version of gcc is preferred or recommended for MacPorts? The one that is in the configure.cc variable. Oh and more generally there is configure.compiler which controls the value of configure.cc, configure.cpp, configure.cxx, configure.fc and so on. See the entries in http://guide.macports.org/#reference.phases.configure. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: What is the preferred or recommended gcc version?
On 2009-05-15 02:00, Darren Weber wrote:
This one is not in the FAQ, yet, so here we go.
Is there a general consensus, for the majority of ports without any
specific build dependency, on which version of gcc is preferred or
recommended for MacPorts?
The following gcc variants are available:
[ dwe...@x ~ ]$ gcc_select -l
Available versions:
gcc40 mp-gcc42 mp-gcc43 mp-gcc44
gcc_select does not control which compiler will be used by MacPorts to
build ports. This is automatically selected in base for the configure
phase and available in the ${configure.cc} variable as Josh mentioned.
The gcc_select tool is only meant to set the compiler which is available
in PATH to the user.
Rainer
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mplayer Variant Help
Thanks. That makes sense. On May 14, 2009, at 12:08 PM, Joshua Root wrote: On 2009-5-15 04:28, EmmGunn wrote: Sorry for being so dense, but what happens when your installing using system 10.5 and there is a darwin_8 variant but no darwin_9 variant? Will the darwin_8 be used and the result work on 10.4, but then be iffy on 10.5? This is the mplayer-devel port file. Nope, darwin_8 variants are only selected on darwin 8 (Tiger). Something built on Tiger and deployed on Leopard has a far better chance of working than the other way round, BTW. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Mpkg Difficulties
Howdy, I don't seem to have very good luck with this. I've been able to install mplayer-devel. I then tried to create a mpkg for mplayer- devel but got the following: sudo port mpkg mplayer-devel Password: --- Fetching mplayer-devel --- Verifying checksum(s) for mplayer-devel --- Extracting mplayer-devel --- Applying patches to mplayer-devel --- Configuring mplayer-devel --- Building mplayer-devel --- Staging mplayer-devel into destroot --- Creating pkg for mplayer-devel-29181 --- Creating pkg for bzip2-1.0.5 Error: Target org.macports.pkg returned: shell command PMResourceLocale=English /Developer/Applications/Utilities/ PackageMaker.app/Contents/MacOS/PackageMaker -AppleLanguages (English) --root /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync .macports.org_release_ports_archivers_bzip2/work/destroot --out / emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync .macports.org_release_ports_multimedia_mplayer-devel/work/mplayer- devel-29181.mpkg/Contents/Packages/bzip2-1.0.5.pkg --resources / emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync .macports.org_release_ports_archivers_bzip2/work/pkg_resources --title bzip2-1.0.5 --info /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync .macports.org_release_ports_archivers_bzip2/work/Info.plist --target 10.3 --domain system --id org.macports.bzip2 returned error 1 Command output: Warning: Unknown argument: -AppleLanguages Warning: Unknown argument: (English) ERROR: The specified root is invalid: /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync .macports.org_release_ports_archivers_bzip2/work/destroot Then it finds a few more ports that it can handle, and then the same error repeats for glib2, libmad, liboil, libpng, perl5.8, and zlib. Any thoughts. Did I miss something important? Was I not supposed to install mplayer-devel before I try to create the mpkg? Thanks in advance for any help. -Mike ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mpkg Difficulties
On May 14, 2009, at 23:23, EmmGunn wrote: Howdy, I don't seem to have very good luck with this. I've been able to install mplayer-devel. I then tried to create a mpkg for mplayer- devel but got the following: sudo port mpkg mplayer-devel Password: --- Fetching mplayer-devel --- Verifying checksum(s) for mplayer-devel --- Extracting mplayer-devel --- Applying patches to mplayer-devel --- Configuring mplayer-devel --- Building mplayer-devel --- Staging mplayer-devel into destroot --- Creating pkg for mplayer-devel-29181 --- Creating pkg for bzip2-1.0.5 Error: Target org.macports.pkg returned: shell command PMResourceLocale=English /Developer/Applications/Utilities/ PackageMaker.app/Contents/MacOS/PackageMaker -AppleLanguages (English) --root /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync.macports.org_release_ports_archive rs_bzip2/work/destroot --out /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync.macports.org_release_ports_multime dia_mplayer-devel/work/mplayer-devel-29181.mpkg/Contents/Packages/ bzip2-1.0.5.pkg --resources /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync.macports.org_release_ports_archive rs_bzip2/work/pkg_resources --title bzip2-1.0.5 --info /emmgunn/ var/macports/build/ _emmgunn_var_macports_sources_rsync.macports.org_release_ports_archive rs_bzip2/work/Info.plist --target 10.3 --domain system --id org.macports.bzip2 returned error 1 Command output: Warning: Unknown argument: -AppleLanguages Warning: Unknown argument: (English) ERROR: The specified root is invalid: /emmgunn/var/macports/build/ _emmgunn_var_macports_sources_rsync.macports.org_release_ports_archive rs_bzip2/work/destroot Then it finds a few more ports that it can handle, and then the same error repeats for glib2, libmad, liboil, libpng, perl5.8, and zlib. Any thoughts. Did I miss something important? Was I not supposed to install mplayer-devel before I try to create the mpkg? Thanks in advance for any help. mpkg is a bit tricky. It needs the destroots of all ports to exist when it tries to package them, but by default MacPorts removes them after a port is installed. You should uninstall mplayer-devel and all its dependencies, then edit your macports.conf and turn autoclean off. Then you can run sudo port mpkg mplayer-devel and it will rebuild itself and all the dependencies and leave a copy of them in the destroot this time, where mpkg will be able to find them. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Mpkg Difficulties
On 2009-5-15 14:23, EmmGunn wrote: Error: Target org.macports.pkg returned: shell command PMResourceLocale=English /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker -AppleLanguages (English) --root /emmgunn/var/macports/build/_emmgunn_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/destroot --out /emmgunn/var/macports/build/_emmgunn_var_macports_sources_rsync.macports.org_release_ports_multimedia_mplayer-devel/work/mplayer-devel-29181.mpkg/Contents/Packages/bzip2-1.0.5.pkg --resources /emmgunn/var/macports/build/_emmgunn_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/pkg_resources --title bzip2-1.0.5 --info /emmgunn/var/macports/build/_emmgunn_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/Info.plist --target 10.3 --domain system --id org.macports.bzip2 returned error 1 Command output: Warning: Unknown argument: -AppleLanguages Warning: Unknown argument: (English) ERROR: The specified root is invalid: /emmgunn/var/macports/build/_emmgunn_var_macports_sources_rsync.macports.org_release_ports_archivers_bzip2/work/destroot That bug is fixed in trunk BTW: http://trac.macports.org/ticket/10881 - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
