Return to site

Compile Universal Binary For Mac

broken image


Building GSL as a Universal Binary. The script I used to build it is below, and is based on this post. If you want to compile it yourself, download the latest version of the GSL (.tar.gz file) from here or one of the mirrors, then run the script below in the same directory. If you're worried about the compiler optimizations affecting accuracy. Feb 21, 2018 A single binary that includes machine code for multiple architectures is called a universal (or 'fat') binary in the Mac lingo. We will use the program lipo to create a universal binary from the two binaries we have compiled. First, we use lipo to examine each binary and confirm that it specifies a single architecture. My idea of working Universal App is that the built example App can run on Intel Mac. And both the lipo tool and the build log show the final App binary are produced from both x8664 and ARM64.

Logo used to indicate a Universal application
Mac transition to
Intel processors

The universal binary format is, in Apple parlance, a format for executable files that run natively on either PowerPC or Intel-manufactured IA-32 or Intel 64-based Macintosh computers. The format originated on NeXTStep as 'Multi-Architecture Binaries', and the concept is more generally known as a fat binary, as seen on Power Macintosh.

With the release of Mac OS X Snow Leopard, and before that, since the move to 64-bit architectures in general, some software publishers such as Mozilla[1] have used the term 'universal' to refer to a fat binary that includes builds for both i386 (32-bit Intel) and x86_64 systems. The same mechanism that is used to select between the PowerPC or Intel builds of an application is also used to select between the 32-bit or 64-bit builds of either PowerPC or Intel architectures.

Apple, however, continued to require native compatibility with both PowerPC and Intel in order to grant third-party software publishers permission to use Apple's trademarks related to universal binaries.[2] Apple does not specify whether or not such third-party software publishers must (or should) bundle separate builds for all architectures.

Universal binaries were introduced into Mac OS at the 2005 Apple Worldwide Developers Conference as a means to ease the transition from the existing PowerPC architecture to systems based on Intel processors, which began shipping in 2006. Universal binaries typically include both PowerPC and x86 versions of a compiled application. The operating system detects a universal binary by its header, and executes the appropriate section for the architecture in use. This allows the application to run natively on any supported architecture, with no negative performance impact beyond an increase in the storage space taken up by the larger binary.

Starting with Mac OS X Snow Leopard, only Intel-based Macs are supported, so software that specifically depends upon capabilities present only in Mac OS X 10.6 or newer will only run on Intel-based Macs and therefore does not require Intel/PPC fat binaries. Additionally, starting with OS X Lion, only 64-bit Intel Macs are supported, so software that specifically depends on new features in OS X 10.7 or newer will only run on 64-bit processors and therefore does not require 32-bit/64-bit fat binaries.[3][4] Fat binaries would only be necessary for software that is designed to have backward compatibility with older versions of Mac OS X running on older hardware.

The new Universal 2 binary format was introduced at the 2020 Worldwide Developers Conference.[5] Universal 2 allows applications to run on both Intelx86-64-based and ARM64-based Macintosh computers, to enable the transition to Apple silicon.

Motivation[edit]

There are two general alternative solutions. The first is to simply provide two separate binaries, one compiled for the x86 architecture and one for the PowerPC architecture. However, this can be confusing to software users unfamiliar with the difference between the two, although the confusion can be remedied through improved documentation, or the use of hybrid CDs. The other alternative is to rely on emulation of one architecture by a system running the other architecture. This approach results in lower performance, and is generally regarded an interim solution to be used only until universal binaries or specifically compiled binaries are available as with Rosetta.

Universal binaries are larger than single-platform binaries, because multiple copies of the compiled code must be stored. However, because some non-executable resources are shared by the two architectures, the size of the resulting universal binary can be, and usually is, smaller than both binaries combined. They also do not require extra RAM because only one of those two copies is loaded for execution.

History[edit]

The concept of a universal binary originated with 'Multi-Architecture Binaries' in NeXTSTEP, the main architectural foundation of Mac OS X. NeXTSTEP supports universal binaries so that one executable image can run on multiple architectures, including Motorola's m68k, Intel's x86, Sun Microsystems's SPARC, and Hewlett-Packard's PA-RISC. NeXTSTEP and macOS use Mach-O archive as the binary format underlying the universal binary.

Apple previously used a similar technique during the transition from 68k processors to PowerPC in the mid-1990s. These dual-platform executables are called fat binaries, referring to their larger file size.

Apple's Xcode 2.1 supports the creation of these files, a new feature in that release. A simple application developed with processor-independence in mind might require very few changes to compile as a universal binary, but a complex application designed to take advantage of architecture-specific features might require substantial modification. Applications originally built using other development tools might require additional modification. These reasons have been given for the delay between the introduction of Intel-based Macintosh computers and the availability of third-party applications in universal binary format. Apple's delivery of Intel-based computers several months ahead of their previously announced schedule is another factor in this gap.

Apple's Xcode 2.4 takes the concept of universal binaries even further, by allowing four-architecture binaries to be created (32- and 64-bit for both Intel and PowerPC), therefore allowing a single executable to take full advantage of the CPU capabilities of any Mac OS X machine.

Universal applications[edit]

Compile Universal Binary For Mac

Many software developers have provided universal binary updates for their products since the 2005 WWDC. As of December 2008, Apple's website listed more than 7,500 Universal applications.[6]

On April 16, 2007, Adobe Systems announced the release of Adobe Creative Suite 3, the first version of the application suite in the Universal Binary format.[7]

From 2006 to 2010, many Mac OS X applications were ported to Universal Binary format, including QuarkXPress, Apple's own Final Cut Studio, Adobe Creative Suite, Microsoft Office 2008, and Shockwave Player with version 11 - after that time most were made Intel-only apps. Non-Universal 32-bit PowerPC programs will run on Intel Macs running Mac OS X 10.4, 10.5, and 10.6 (in most cases), but with non-optimal performance, since they must be translated on-the-fly by Rosetta; they will not run on Mac OS X 10.7 Lion and later as Rosetta is no longer part of the OS.

iOS[edit]

Apple has used the same binary format as Universal Binaries for iOS applications by default on multiple occasions of architectural co-existence: around 2010 during the armv6-armv7-armv7s transition and around 2016 during the armv7-arm64 transition. The App Store automatically thins the binaries. No trade names were derived for this practice, as it is only a concern of the developer.[8]

Universal 2[edit]

Mac transition to
Apple Silicon

On June 22, 2020, Apple announced a two-year permanent transition from Intelx86-64-based processors to ARM64-based Apple silicon beginning with macOS Big Sur in late 2020.[9] To aid in this transition, a new Universal 2 binary was introduced to enable applications to be run on either x86-64-based processors or ARM64-based processors.[5]

Tools[edit]

The main tool for handling (creating or splitting) universal binaries is the lipo command found in Xcode. The file command on macOS and several other Unix-like systems can identify Mach-O universal binaries and report architecture support.[10]Snow Leopard's System Profiler provides this information on the Applications tab.

See also[edit]

  • Xslimmer, a commercial Mac OS X application that allows the user to slim down the fat universal binaries by removing the code for the platform that is not in use.

References[edit]

  1. ^'Firefox 4 for Mac OS X: Under the Hood'. November 10, 2010. Retrieved March 3, 2017.
  2. ^'Mac OS X Universal Logo: Guidelines for Mac OS X Universal Logo Licenses'(PDF). Apple Inc. June 2007. Retrieved October 18, 2013.
  3. ^'Mac OS X: 64-bit kernel frequently asked questions'. Apple Inc. October 4, 2012. Retrieved October 18, 2013.
  4. ^'Does Mac OS X 10.7 'Lion' run on Macs with a 32-bit EFI? How does the performance of Mac OS X 10.7 'Lion' compare to Mac OS X 10.6 'Snow Leopard' in 'real-world' tests? @ EveryMac.com'. everymac.com. Kyle Media. Retrieved October 6, 2017.
  5. ^ abAxon, Samuel (June 22, 2020). 'This is Apple's roadmap for moving the first Macs away from Intel'. Ars Technica. Retrieved June 23, 2020.
  6. ^'Macintosh Products Guide: Universal Applications'. Apple Computer. Retrieved December 22, 2008.
  7. ^'Adobe Ships Creative Suite 3'. Adobe Systems. April 16, 2007. Archived from the original on July 8, 2012. Retrieved October 18, 2013.
  8. ^'lipo - iOS fat binaries and thinning out'. Stack Overflow.
  9. ^Amadeo, Ron (June 22, 2020). 'Apple announces macOS 11, 'Big Sur,' with an emphasis on design'. Ars Technica. Retrieved June 23, 2020.
  10. ^stany (September 6, 2005). 'Mac OS X: Trimming fat from Mach-O fat files'. theconsultant.net. Retrieved October 18, 2013.

External links[edit]

  • Apple Developer Transition Resource Center
  • Apple Universal Binary Programming Guidelines
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Universal_binary&oldid=989346749'

English | Deutsch | Español | Français | Italiano

How to get and install aMule on Apple Mac OS X.

  1. You can simply download the finished application ('binary release');
  2. You compile it from a SVN source snapshot or stable release source.
  • 2Compiling from source
    • 2.1Get the sources and development tools
      • 2.1.2Step 2: Install MacPorts
      • 2.1.4Step 4: Compile wxMac
Binary

Binary releases

If you don't want to bother with installing and compiling all those tools and sources, then get one of the pre-compiled aMule applications. The official release is considered 'stable', but every now and then applications are built from the current source to allow more people to test new features or the like.

Check the Mac forum for the most recent user posted binary: aMule forum

Now, to install the downloaded binary, just drag the aMule application to a folder of your choice (e.g., /Applications).

To start aMule, double-click the application icon.

Note: You might want to take a look at the Mac-specific usage article.

Compiling from source

Compiling from source allows most current bug reports, because you can compile and test the SVN snapshot of the very day.

To compile aMule from source you need some development tools, the wxWidgets library and the aMule source.

Get the sources and development tools

Step 1: Download and install Xcode

Xcode is Apple's development environment. We need it for the GCC compiler.

You will need at least version 2.1 of Xcode, a more recent version is preferable though. You can download the most recent version of Xcode from Apple, but you will need to sign up for a free-of-charge developer account first or log-in using your iTunes Store account.

  1. Get Xcode from http://developer.apple.com/tools/download
  2. 'Member Site'->'Log In'->'Download Software'->'Developer Tools'->'Download Xcode Tools last release'>'Install'

Step 2: Install MacPorts

MacPorts is an open source installer for lots of open source tools ported to Mac OS X. aMule needs a few of these tools to compile properly. Alternatively, you can also use Fink to install these tools or (Fink currently lacks many of the needed tools) you can install them manually .

  1. Download the most recent version of MacPorts
  2. Read MacPorts' documentation to learn how to install applications through MacPorts.

Compile Universal Binary For Mac Windows 7

Syntax of most important commands

Packages list can be downloaded/updated through

You can upgrade all the packages installed with

Packages can be installed through

and removed with

Port variants can be invoked with the plus sign:

You can list all available variants with:

Compile Universal Binary For Mac Windows 10

Notes about Universal variant

As stated here, MacPorts has different build_arch settings for universal variant. You can use this variant on Leopard to switch both ppc and i386 version on. Since Snow Leopard doesn't support ppc architecture anymore, the universal variant can be used to switch both i386 and x86_64 version on. Please note that default architecture on Snow Leopard is x86_64 if the CPU supports it, i386 otherwise.

WARNING: binutilsfails building universal. So you should set build_arch to i386 (about line 59) into /opt/local/etc/macports/macports.conf to be sure to build every port against i386 architecture (x86_64 is useless since 64-bit Carbon libraries does not exists and wxCocoa is not ready yet).

Step 3: Install libraries and tools

These are the package that provides (with dependancies) all needed libraries and tools to build wxWidgets and aMule with most of feature:

  1. automake
  2. binutils
  3. flex
  4. gettext
  5. libpng
  6. libcryptopp
  7. libiconv
  8. gd2
  9. jpeg
  10. libgeoip
  11. libupnp
  12. pkgconfig

This should be enough:

Step 4: Compile wxMac

wxMac is the port of the wxWidgets library for Mac OS X. This library is used to make aMule 'multi-platform'.

Get the source from: http://www.wxwidgets.org/downloads/ (Source Archives: wxMac) and extract the archive on your desktop.
Last stable version is 2.8.11 at now.Type

leave a space after the command, than drag and drop the wxMac uncompressed folder into the Terminal window: the complete path of the folder will be printed on screen. For example:

Mac Universal Binary

Press enter.The basic command to configure and compile the package is the following:

Note: The above command doesn't enable debug information. Debug informations allows you to submit a helpful stacktrace if aMule crashes or a sample if it hangs to the aMule developers. If you want to compile a debug version then you can use '--enable-debug --enable-debug_gdb' instead.

Compile Universal Binary For Mac X

Snow Leopard

Building on Snow Leopard is tricky. You must focus on architecture, compiler version, compatibility. This should be enough to have compatibility with i386 Leopard and above:

followed by:

Compile universal binary for mac pro

Starting with Mac OS X Snow Leopard, only Intel-based Macs are supported, so software that specifically depends upon capabilities present only in Mac OS X 10.6 or newer will only run on Intel-based Macs and therefore does not require Intel/PPC fat binaries. Additionally, starting with OS X Lion, only 64-bit Intel Macs are supported, so software that specifically depends on new features in OS X 10.7 or newer will only run on 64-bit processors and therefore does not require 32-bit/64-bit fat binaries.[3][4] Fat binaries would only be necessary for software that is designed to have backward compatibility with older versions of Mac OS X running on older hardware.

The new Universal 2 binary format was introduced at the 2020 Worldwide Developers Conference.[5] Universal 2 allows applications to run on both Intelx86-64-based and ARM64-based Macintosh computers, to enable the transition to Apple silicon.

Motivation[edit]

There are two general alternative solutions. The first is to simply provide two separate binaries, one compiled for the x86 architecture and one for the PowerPC architecture. However, this can be confusing to software users unfamiliar with the difference between the two, although the confusion can be remedied through improved documentation, or the use of hybrid CDs. The other alternative is to rely on emulation of one architecture by a system running the other architecture. This approach results in lower performance, and is generally regarded an interim solution to be used only until universal binaries or specifically compiled binaries are available as with Rosetta.

Universal binaries are larger than single-platform binaries, because multiple copies of the compiled code must be stored. However, because some non-executable resources are shared by the two architectures, the size of the resulting universal binary can be, and usually is, smaller than both binaries combined. They also do not require extra RAM because only one of those two copies is loaded for execution.

History[edit]

The concept of a universal binary originated with 'Multi-Architecture Binaries' in NeXTSTEP, the main architectural foundation of Mac OS X. NeXTSTEP supports universal binaries so that one executable image can run on multiple architectures, including Motorola's m68k, Intel's x86, Sun Microsystems's SPARC, and Hewlett-Packard's PA-RISC. NeXTSTEP and macOS use Mach-O archive as the binary format underlying the universal binary.

Apple previously used a similar technique during the transition from 68k processors to PowerPC in the mid-1990s. These dual-platform executables are called fat binaries, referring to their larger file size.

Apple's Xcode 2.1 supports the creation of these files, a new feature in that release. A simple application developed with processor-independence in mind might require very few changes to compile as a universal binary, but a complex application designed to take advantage of architecture-specific features might require substantial modification. Applications originally built using other development tools might require additional modification. These reasons have been given for the delay between the introduction of Intel-based Macintosh computers and the availability of third-party applications in universal binary format. Apple's delivery of Intel-based computers several months ahead of their previously announced schedule is another factor in this gap.

Apple's Xcode 2.4 takes the concept of universal binaries even further, by allowing four-architecture binaries to be created (32- and 64-bit for both Intel and PowerPC), therefore allowing a single executable to take full advantage of the CPU capabilities of any Mac OS X machine.

Universal applications[edit]

Many software developers have provided universal binary updates for their products since the 2005 WWDC. As of December 2008, Apple's website listed more than 7,500 Universal applications.[6]

On April 16, 2007, Adobe Systems announced the release of Adobe Creative Suite 3, the first version of the application suite in the Universal Binary format.[7]

From 2006 to 2010, many Mac OS X applications were ported to Universal Binary format, including QuarkXPress, Apple's own Final Cut Studio, Adobe Creative Suite, Microsoft Office 2008, and Shockwave Player with version 11 - after that time most were made Intel-only apps. Non-Universal 32-bit PowerPC programs will run on Intel Macs running Mac OS X 10.4, 10.5, and 10.6 (in most cases), but with non-optimal performance, since they must be translated on-the-fly by Rosetta; they will not run on Mac OS X 10.7 Lion and later as Rosetta is no longer part of the OS.

iOS[edit]

Apple has used the same binary format as Universal Binaries for iOS applications by default on multiple occasions of architectural co-existence: around 2010 during the armv6-armv7-armv7s transition and around 2016 during the armv7-arm64 transition. The App Store automatically thins the binaries. No trade names were derived for this practice, as it is only a concern of the developer.[8]

Universal 2[edit]

Mac transition to
Apple Silicon

On June 22, 2020, Apple announced a two-year permanent transition from Intelx86-64-based processors to ARM64-based Apple silicon beginning with macOS Big Sur in late 2020.[9] To aid in this transition, a new Universal 2 binary was introduced to enable applications to be run on either x86-64-based processors or ARM64-based processors.[5]

Tools[edit]

The main tool for handling (creating or splitting) universal binaries is the lipo command found in Xcode. The file command on macOS and several other Unix-like systems can identify Mach-O universal binaries and report architecture support.[10]Snow Leopard's System Profiler provides this information on the Applications tab.

See also[edit]

  • Xslimmer, a commercial Mac OS X application that allows the user to slim down the fat universal binaries by removing the code for the platform that is not in use.

References[edit]

  1. ^'Firefox 4 for Mac OS X: Under the Hood'. November 10, 2010. Retrieved March 3, 2017.
  2. ^'Mac OS X Universal Logo: Guidelines for Mac OS X Universal Logo Licenses'(PDF). Apple Inc. June 2007. Retrieved October 18, 2013.
  3. ^'Mac OS X: 64-bit kernel frequently asked questions'. Apple Inc. October 4, 2012. Retrieved October 18, 2013.
  4. ^'Does Mac OS X 10.7 'Lion' run on Macs with a 32-bit EFI? How does the performance of Mac OS X 10.7 'Lion' compare to Mac OS X 10.6 'Snow Leopard' in 'real-world' tests? @ EveryMac.com'. everymac.com. Kyle Media. Retrieved October 6, 2017.
  5. ^ abAxon, Samuel (June 22, 2020). 'This is Apple's roadmap for moving the first Macs away from Intel'. Ars Technica. Retrieved June 23, 2020.
  6. ^'Macintosh Products Guide: Universal Applications'. Apple Computer. Retrieved December 22, 2008.
  7. ^'Adobe Ships Creative Suite 3'. Adobe Systems. April 16, 2007. Archived from the original on July 8, 2012. Retrieved October 18, 2013.
  8. ^'lipo - iOS fat binaries and thinning out'. Stack Overflow.
  9. ^Amadeo, Ron (June 22, 2020). 'Apple announces macOS 11, 'Big Sur,' with an emphasis on design'. Ars Technica. Retrieved June 23, 2020.
  10. ^stany (September 6, 2005). 'Mac OS X: Trimming fat from Mach-O fat files'. theconsultant.net. Retrieved October 18, 2013.

External links[edit]

  • Apple Developer Transition Resource Center
  • Apple Universal Binary Programming Guidelines
Retrieved from 'https://en.wikipedia.org/w/index.php?title=Universal_binary&oldid=989346749'

English | Deutsch | Español | Français | Italiano

How to get and install aMule on Apple Mac OS X.

  1. You can simply download the finished application ('binary release');
  2. You compile it from a SVN source snapshot or stable release source.
  • 2Compiling from source
    • 2.1Get the sources and development tools
      • 2.1.2Step 2: Install MacPorts
      • 2.1.4Step 4: Compile wxMac

Binary releases

If you don't want to bother with installing and compiling all those tools and sources, then get one of the pre-compiled aMule applications. The official release is considered 'stable', but every now and then applications are built from the current source to allow more people to test new features or the like.

Check the Mac forum for the most recent user posted binary: aMule forum

Now, to install the downloaded binary, just drag the aMule application to a folder of your choice (e.g., /Applications).

To start aMule, double-click the application icon.

Note: You might want to take a look at the Mac-specific usage article.

Compiling from source

Compiling from source allows most current bug reports, because you can compile and test the SVN snapshot of the very day.

To compile aMule from source you need some development tools, the wxWidgets library and the aMule source.

Get the sources and development tools

Step 1: Download and install Xcode

Xcode is Apple's development environment. We need it for the GCC compiler.

You will need at least version 2.1 of Xcode, a more recent version is preferable though. You can download the most recent version of Xcode from Apple, but you will need to sign up for a free-of-charge developer account first or log-in using your iTunes Store account.

  1. Get Xcode from http://developer.apple.com/tools/download
  2. 'Member Site'->'Log In'->'Download Software'->'Developer Tools'->'Download Xcode Tools last release'>'Install'

Step 2: Install MacPorts

MacPorts is an open source installer for lots of open source tools ported to Mac OS X. aMule needs a few of these tools to compile properly. Alternatively, you can also use Fink to install these tools or (Fink currently lacks many of the needed tools) you can install them manually .

  1. Download the most recent version of MacPorts
  2. Read MacPorts' documentation to learn how to install applications through MacPorts.

Compile Universal Binary For Mac Windows 7

Syntax of most important commands

Packages list can be downloaded/updated through

You can upgrade all the packages installed with

Packages can be installed through

and removed with

Port variants can be invoked with the plus sign:

You can list all available variants with:

Compile Universal Binary For Mac Windows 10

Notes about Universal variant

As stated here, MacPorts has different build_arch settings for universal variant. You can use this variant on Leopard to switch both ppc and i386 version on. Since Snow Leopard doesn't support ppc architecture anymore, the universal variant can be used to switch both i386 and x86_64 version on. Please note that default architecture on Snow Leopard is x86_64 if the CPU supports it, i386 otherwise.

WARNING: binutilsfails building universal. So you should set build_arch to i386 (about line 59) into /opt/local/etc/macports/macports.conf to be sure to build every port against i386 architecture (x86_64 is useless since 64-bit Carbon libraries does not exists and wxCocoa is not ready yet).

Step 3: Install libraries and tools

These are the package that provides (with dependancies) all needed libraries and tools to build wxWidgets and aMule with most of feature:

  1. automake
  2. binutils
  3. flex
  4. gettext
  5. libpng
  6. libcryptopp
  7. libiconv
  8. gd2
  9. jpeg
  10. libgeoip
  11. libupnp
  12. pkgconfig

This should be enough:

Step 4: Compile wxMac

wxMac is the port of the wxWidgets library for Mac OS X. This library is used to make aMule 'multi-platform'.

Get the source from: http://www.wxwidgets.org/downloads/ (Source Archives: wxMac) and extract the archive on your desktop.
Last stable version is 2.8.11 at now.Type

leave a space after the command, than drag and drop the wxMac uncompressed folder into the Terminal window: the complete path of the folder will be printed on screen. For example:

Mac Universal Binary

Press enter.The basic command to configure and compile the package is the following:

Note: The above command doesn't enable debug information. Debug informations allows you to submit a helpful stacktrace if aMule crashes or a sample if it hangs to the aMule developers. If you want to compile a debug version then you can use '--enable-debug --enable-debug_gdb' instead.

Compile Universal Binary For Mac X

Snow Leopard

Building on Snow Leopard is tricky. You must focus on architecture, compiler version, compatibility. This should be enough to have compatibility with i386 Leopard and above:

followed by:

Step 5: Compile aMule

Download aMule source and extract archive into the same place of wxMac (i.e. your desktop if you are following out suggestion).Open a Terminal and type:

then leave a space and drag and drop aMule uncompressed folder whose path will be printed on screen, for example:

Press Enter. Now it's possible to configure the sources: there are several options that can be used to activate or deactivate feature during compiling. This is only an example, that provide a full feature aMule build:

Take a look to the configure page for a complete list of options.You should pay attention to these elements:

  1. The given example enables debug informations. To disable them exchange the option --enable-debug with --disable-debug --enable-optimize.
  2. The option --with-wx-config must point to the correct relative path of the compiled wxMac. The example assumes that aMule and wxMac folders are in the same directory (i.e. your desktop). You should also correct the wxMac folder's name according to its version (in the example is 2.8.10).
  3. The option --with-crypto-prefix should point to /usr/local/cryptopp if you compiled Crypto++ starting from its source, out of MacPorts.
  4. IMPORTANT! It seems that Mac OS version of ld tool is not able to make static library. So if you plan to run/install your compiled aMule on other Mac which doesn't have MacPorts installed you MUST remove the --enable-geoip-static option to avoid a crash when the program starts.

Now it's time to make you packages with:

and

You should find the aMule package in the same source folder.

Retrieved from 'http://wiki.amule.org/t/index.php?title=HowTo_compile_on_Mac&oldid=28412'




broken image