MacPorts

[ilg-ul]

I appreciate your effort to maintain this project, but I'm a bit disappointed you do not use MacPorts as complementary tools but favour Homebrew.

MacPorts may have many problems, but I think it has the most traction now, there are more than 8000 ports available.

I did some experiments, but they failed. I also tried with the latest 2011.03-42, but also without success.

• I installed the dependencies with

sudo port install mpfr gmp libmpc texinfo

• I added

DEPENDENCY_PATH=/opt/local

• and

--with-mpc=$(DEPENDENCY_PATH) --with-mpfr=$(DEPENDENCY_PATH) --with-gmp=$(DEPENDENCY_PATH)

Other definition used are

CS_BASE = 2011.03 CS_REV = 42 GCC_VERSION = 4.5 MPC_VERSION = 0.8.1 CS_VERSION = $(CS_BASE)-$(CS_REV) LOCAL_BASE = arm-$(CS_VERSION)-arm-none-eabi LOCAL_SOURCE = $(LOCAL_BASE).src.tar.bz2 LOCAL_BIN = $(LOCAL_BASE)-i686-pc-linux-gnu.tar.bz2 SOURCE_URL = http://www.codesourcery.com/sgpp/lite/arm/portal/package8733/public/arm-none-eabi/$(LOCAL_SOURCE)

BIN_URL = http://www.codesourcery.com/sgpp/lite/arm/portal/package7813/public/arm-none-eabi/$(LOCAL_BIN)

SOURCE_MD5_CHCKSUM = 7c302162ec813d039b8388bd7d2b4176

BIN_MD5_CHECKSUM = 273e0c8da3111244957935aa4d6da197

It would be great if you could port the build procedure for MacPorts.

I offer to help with testing and any support you suggest.

Regards,

Liviu

p.s. the moment when the make cross-gcc fails is the following

ar rc libbackend.a insn-attrtab.o ... varpool.o /usr/bin/ranlib: file: libbackend.a(graphite-blocking.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-clast-to-gimple.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-dependences.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-interchange.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-poly.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-ppl.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-scop-detection.o) has no symbols /usr/bin/ranlib: file: libbackend.a(graphite-sese-to-poly.o) has no symbols /usr/bin/ranlib: file: libbackend.a(loop-doloop.o) has no symbols /usr/bin/ranlib: file: libbackend.a(vmsdbgout.o) has no symbols /usr/bin/ranlib: file: libbackend.a(xcoffout.o) has no symbols ranlib -c libbackend.a ranlib: file: libbackend.a(graphite-blocking.o) has no symbols ranlib: file: libbackend.a(graphite-clast-to-gimple.o) has no symbols ranlib: file: libbackend.a(graphite-dependences.o) has no symbols ranlib: file: libbackend.a(graphite-interchange.o) has no symbols ranlib: file: libbackend.a(graphite-poly.o) has no symbols ranlib: file: libbackend.a(graphite-ppl.o) has no symbols ranlib: file: libbackend.a(graphite-scop-detection.o) has no symbols ranlib: file: libbackend.a(graphite-sese-to-poly.o) has no symbols ranlib: file: libbackend.a(loop-doloop.o) has no symbols ranlib: file: libbackend.a(vmsdbgout.o) has no symbols ranlib: file: libbackend.a(xcoffout.o) has no symbols gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o arm-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \ dummy-checksum.o main.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a -liconv ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/opt/local/lib -L/opt/local/lib -L/opt/local/lib -lmpc -lmpfr -lgmp -L../zlib -lz Undefined symbols: "_iconv_close", referenced from: cpp_destroy_iconv in libcpp.a(charset.o) cpp_destroy_iconv in libcpp.a(charset.o) cpp_destroy_iconv in libcpp.a(charset.o) cpp_destroy_iconv in libcpp.a(charset.o) cpp_destroy_iconv in libcpp.a(charset.o) cpp_convert_input in libcpp.a(charset.o) "_iconv", referenced from: _convert_using_iconv in libcpp.a(charset.o) _convert_using_iconv in libcpp.a(charset.o) _convert_using_iconv in libcpp.a(charset.o) _convert_using_iconv in libcpp.a(charset.o) (maybe you meant: __cpp_destroy_iconv, _cpp_init_iconv ) "_iconv_open", referenced from: _init_iconv_desc in libcpp.a(charset.o) ld: symbol(s) not found collect2: ld returned 1 exit status make[3]: * [cc1-dummy] Error 1 rm gcov.pod gfdl.pod cpp.pod gcc.pod fsf-funding.pod make[2]: * [all-gcc] Error 2 make[1]: * [all] Error 2 make: * [cross-gcc] Error 2 rm arm-2011.03-42-arm-none-eabi/binutils-2011.03-42.tar.bz2 ilg-mbp:jsnyder-arm-eabi-toolchain-b7241de ilg$

[jsnyder]

I originally had the makefile building those dependencies as well, but switched to homebrew for 2 reasons: 1) mpfr and gmp weren't detecting core i7 machines correctly and were building as 32-bit. (This easier to deal with in the latest versions of these libraries, but I didn't really like installing these on people's systems without being tracked by a package manager anyways. I could have modified the build to keep them in a temporary build directory, but this was added complication.) 2) Using Homebrew, at least for me, required zero changes to the Makefile, and I like trying to keep this as generic and simple as possible

As a potential avenue for how to address this, I took a look at the gcc45 port for macports: https://trac.macports.org/browser/trunk/dports/lang/gcc45/Portfile

This sounds like it might be relevant: 105 # do NOT use MacPorts binutils -- they do not work 106 configure.env-append AR_FOR_TARGET=/usr/bin/ar \ 107 AS_FOR_TARGET=/usr/bin/as \ 108 LD_FOR_TARGET=/usr/bin/ld \ 109 NM_FOR_TARGET=/usr/bin/nm \ 110 OBJDUMP_FOR_TARGET=/usr/bin/objdump \ 111 RANLIB_FOR_TARGET=/usr/bin/ranlib \ 112 STRIP_FOR_TARGET=/usr/bin/strip

So, as a first run I'd recommend adding to what you already tried by defining these as well. Given where it failed it sounds like this might be what's needed.

As a side note, if this is the issue, this is the sort of thing that drove me away from MacPorts in the first place :-) I've had a number of headaches with it where while it may build and install more recent versions of things Apple only updates infrequently, they're not always functionally equivalent replacements. Homebrew isn't perfect, but I've had fewer issues of this sort with it.

I'd be perfectly happy with adding a script or something that pre-defines these or adding something to the instructions. I'd be slightly less happy with adding platform-specific stuff to the Makefile, but lets see what might work as a solution to this issue.

[ilg-ul]

2) Using Homebrew, at least for me, required zero changes to the Makefile, and I like trying to keep this as generic and simple as possible

I have a problem with distributions that install anything in the system folders, and Homebrew insists in using the /usr/local. :-(

As a potential avenue for how to address this, I took a look at the gcc45 port for macports: ... 105 # do NOT use MacPorts binutils -- they do not work ... So, as a first run I'd recommend adding to what you already tried by defining these as well. Given where it failed it sounds like this might be what's needed.

I did not have MacPorts binutils installed on my machine, so the problem is probably somewhere else.

... the sort of thing that drove me away from MacPorts in the first place

You are probably right :-(

But I would not give up as easily. I fully support open source projects, and if there are problems and I can identify them, why not help the maintainer fix them?

I did the following test: I ran make cross-gcc with and without MacPorts (that's one of the things I like at Macports, you just remove the /opt/* references from the PATH, and you get rid of it). The build failed exactly in the same place, with the same error.

The only reference to MacPorts was the DEPENDENCY_PATH, for the mpfr gmp libmpc.

... Homebrew isn't perfect, but I've had fewer issues of this sort with it.

I'll try to install Homebrew in a separate folder and retry the test with references to it.

I'd be perfectly happy with adding a script or something that pre-defines these or adding something to the instructions. I'd be slightly less happy with adding platform-specific stuff to the Makefile, but lets see what might work as a solution to this issue.

Ok, first let's see how can fully build the toolchain, and then discuss on how to proceed with the makefile.

Could you check if your build works on the latest 2011.03 Sourcery release?

Regards,

Liviu

[ilg-ul]

I installed Homebrew in a separate folder and when pointing the dependencies to it, the cross-gcc build completed properly.

After changing the reference to MacPorts, the build failed.

This confirms your conclusion that the MacPorts versions of mpc/mpfr/gmp are buggy, even if they are now at the latest versions, so I suppose there is something wrong with the build process.

Using Homebrew as a reference, I'll try to isolate where the problem is.

Regards,

Liviu

[jsnyder]

It might also be related to this: https://trac.macports.org/ticket/13499

Here are some similar ones for cross-compiler GCC builds: https://trac.macports.org/ticket/16662 https://trac.macports.org/ticket/16487

Boiling down from these maybe prepending "-L/usr/lib" for the LIBINTL define as in this patch: https://trac.macports.org/browser/trunk/dports/cross/i386-elf-gcc/files/patch-gcc-Makefile.in?rev=36032 and/or: adding macports' include path to the C compiler flags? similar to this: https://trac.macports.org/attachment/ticket/16662/Portfile.patch

The first of these might be a little bit of a pain with the way this Makefile groups parts of the building process and kindof starts from scratch if you run it again (I have an alternate approach my more recently added avr32-toolchain build, but I haven't updated this one to that style yet). If you're comfortable with Makefiles and patches you could probably adapt the MacPorts patch file and have the Makefile apply it.

Regarding MacPorts overriding things, I didn't mean that it installed anything outside of /opt (hopefully no packages do), but that one ends up with duplicate and different versions of tools that Apple provides just by building up a basic MacPorts install, and what ends up happening is that when other stuff builds it sometimes partly picks up header files from MacPorts or Apple versions but tries to link with the other. I think this might be even more common than the issues with installed packages providing different functionality. In short, it means one has to be very careful about paths and environmental variables, and I think a lot of the ports themselves, certainly more complicated ones like GCC, end up with patches or fixes not so much for issues with the Mac platform, but to work around forcing it to use either Apple's built-in tools or MacPorts tools or libraries depending on whether or not the MacPorts versions work correctly.

[ilg-ul]

You are right, most of the existing makefiles were not designed with multiple versions of header/libraries in various folders, and controlling the inclusion order is quite tricky.

I installed the three dependency libraries with Homebrew in a separate folder, and I had to remove them from MacPorts in order for the build to succeed. Attempts to isolate one of the libraries in Homebrew and the other two in MacPorts failed, exactly due to Makefile impossibility to control the inclusion order.

I am a bit disappointed by the situation, mixing distributions seems a never ending story. On my first Mac I manually installed (configure/make install) libraries over the system (/usr/local) when needed, and ended up with not knowing what is installed, which version, etc. On my new Mac I decided to never touch the system, and install everything in separate folders, preferably with MacPorts.

Both are evil, but the question is which one is the lesser evil?

Would it be possible to run the build with references only to MacPorts and without references to the Apple headers/libraries?

I took a look at the links you provided, I'll give them a try, but since they are quite old, I don't expect miracles.

Regards,

Liviu

p.s. BTW, the avr32-toolchain build is functional?

[jsnyder]

Both are evil, but the question is which one is the lesser evil?

This is the perennial question, I think :-) I think they both have positives and negatives,and I'm sure that people would argue with religious fervor on both sides. If you use things like Homebrew which explicitly don't replace Apple's stuff, you end up with stale versions of things that Apple has shipped. If you install something like MacPorts, you end up with multiple versions which are complicated to deal with. I think a lot of this would be less complicated if the Apple tools were either less patched or were available in upstream distributions. While I believe they do make their patches available, I don't think they tend to get integrated into upstream distributions since they're sometimes rather extensive to support things like universal binaries and support switching between code within such universal binaries. Also, Apple has a mixture of GNU and BSD tools, so for some things the GNU version really isn't the same thing but newer.

Would it be possible to run the build with references only to MacPorts and without references to the Apple headers/libraries?

Well, I think it's always a bit of a hybrid, even for ports in MacPorts. I would try following the gcc packages in MacPorts as a model if you'd like to do this though. I suppose this could be made into a port?

p.s. BTW, the avr32-toolchain build is functional?

It should be. I've been informed by someone that one step might have gotten left out in building binutils I believe, which I'll commit a fix for today, but even without that I've gotten it to successfully build and work for me at least. Note that it will have similar issues in terms of requiring mpfr etc.. which I just suggested people install from Homebrew. I think I also have a binary distribution for it as I do for the arm toolchain, neither of which should require installing anything special, though if you're like me you probably want to minimize the number of binary blobs you're trusting from random people :-)

The avr32-toolchain is actually one thing that might debatably become slightly less complicated if it used Macports since I have to build special versions of autotools to reconfigure everything after patching, although I haven't checked whether MacPorts ships the requisite versions (gcc and other parts of the GNU toolchain require certain versions of autoconf etc.. to be run on them). Fortunately that stuff isn't painful to compile and it gets installed in a temporary directory just used during the build.

[ilg-ul]

I suppose this could be made into a port?

that would be great...

I would try following the gcc packages in MacPorts as a model if you'd like to do this though.

ok, I'll take a look, but the first step was to manually build on MacPorts and I still have to work on it :-(

The avr32-toolchain ... Macports ... special versions of autotools

yes, I remember this, I also tried to build the avr32 toolchainonce, but it required too many old dependencies, and gave up.

if you have a makefile that succeeds, even with Homebrew, that would be useful.

regards,

Liviu

[jsnyder]

On Mon, Jun 27, 2011 at 12:20 PM, ilg-ul reply@reply.github.com wrote:

I suppose this could be made into a port?

that would be great...

I'm not sure what the policies would be regarding how this is actually an amalgamation of gcc+binutils+newlib, maybe there are some other cross-compiling toolchains that could be used as templates. Presumably it wouldn't be the same as this makefile, but something working could be imported and then

I would try following the gcc packages in MacPorts as a model if you'd like to do this though.

ok, I'll take a look, but the first step was to manually build on MacPorts and I still have to work on it :-(

Yeah, I dunno, maybe if the latest version of CodeSourcery's release includes late enough versions of mpfr etc.. I can internalize those dependencies again, or provide that as an option.

Let me know if you have any luck. I have had the intention of looking at this myself for some time but I've not gotten too deep into it for reasons previously discussed and outlined :-)

The avr32-toolchain ... Macports ... special versions of autotools

yes, I remember this, I also tried to build the avr32 toolchainonce, but it required too many old dependencies, and gave up.

Yep, It should be working on 10.6. If it fails, definitely let me know. I just built it today for the commit I made.

It does take a bit longer to build though since it has to build its own auto* tools, patch and regenerate some of the build system scripts before going ahead.

if you have a makefile that succeeds, even with Homebrew, that would be useful.

Works for me with Homebrew. And I believe I've checked it on Linux as well and had anecdotal support that it worked on someone else's linux system. I made it because I couldn't find any decent builds of an avr32 toolchain for the Mac.

regards,

Liviu

Reply to this email directly or view it on GitHub: https://github.com/jsnyder/arm-eabi-toolchain/issues/7#issuecomment-1448888

[joerlane]

I too ran into this problem with MacPorts by assuming I could install the required packages through there instead of homebrew. A quick mention of this in the Readme could have saved some hours of trouble and confusion; luckily I noticed this thread before the frustration set in. It was an informative struggle though and everything is working after I deactivated mpfr, gmp and libmpc with the port command then installed those three packages through homebrew. As a side note I ended up deactivating the $PATH variables relating to MacPorts altogether because .bash_profile supersedes the .profile that appears to have been installed with MacPorts; I did not have those paths mapped when I compiled the tool-chain successfully (not sure if it mattered). At long last though, I am able to compile for the Stellaris Launchpad and for that I must thank you.