Re: [crosstool-ng] Menuconfig problems on Mac OS X

[Arnaud Lacombe <lacombar at gmail dot com>]

Hi,

On Sun, Jun 26, 2011 at 6:00 PM, Titus von Boxberg <titus@v9g.de> wrote:
> Am 26.06.2011 um 18:43 schrieb Yann E. MORIN:
>
>> Titus, All,
>>
>> On Sunday 26 June 2011 16:07:23 Titus von Boxberg wrote:
>>>>>> Yann, is there a chance that you reapply my patches to kconfig?
>>>> hg diff -c 20f02d426e15
>>> I did not get an answer.
>>> Is there a chance for these changes to be reapplied and stay in?
>>> Or is a change in kconfig unwanted?
>>
>> The fact is, there are changes being pushed to kconfig that I initiated
>> and will be initiating (by bugging them on their list), so I will from
>> time to time resync with upstream kconfig.
>>
>> From what I understand from the messages on the list, the problem with
>> MacOS-X is that there can be two different implementations of the same
>> thing. For example, one can use the native gcc (from X-Code?), or the
>> gcc from MacPorts; and those two are different beasts. Same seems to go
>> for curses. And probably a bunch of other things.
>>
>> I do not want to add too many workarounds / shortcuts / escape ways for
>> each possible combinations.
>>
>> So, either we support MacOS-X without MacPorts at all, or we require
>> MacPorts to be installed, and take everything from there.
> Yann, Bryan, all,
>
> 1) "everything" is hard to automatically get if you're not about to
> ? (manually) convert your mac (before using ct-ng) into some strange
> ? mixture of GNU and Mac which I felt is definitely not the way to go.
> ? And "everything" is also hard to define because ct-ng is written on
> ? Linux and despite the extensive configure script ct-ng pulled in things
> ? unchecked that are not present on nonGNU systems.
> ? That's also why I patched all ct-ng code that required GNU coreutils
> ? because I feel it's a bad idea and normally unnecessary to install
> ? GNU coreutils into your PATH on a BSD/Mac system.
FWIW, just having an hard dependency on bash(1), rather than sh(1) is
an aberration...

 - Arnaud

> 2) Neither extreme will (safely) work.
>
> Some explanations for the macport's software parts I found to be necessary:
>
> ---- ? ncurses
> This is necessary due to a bug / incompatibility in apple's ncurses
> for which I posted a link to explain. Not using the mp-version prevents on my mac
> the cursor keys working in menuconfig.
>
> Bryan: Did you check if the right ncurses gets pulled in although
> the kconfig patches are gone? Or does it work by some other magic?
> What does "otool -L kconfig/mconf" say on your system?
>
> ---- ? lzmautils
> Can only guess for what it's used.
>
> ---- ? binutils
> If I remember correctly requiring it is due to a failure
> in the build (system?) of eglibc. I posted a mail with patches
> for building eglibc-2_9 on a Mac. The explanation is in there:
> http://sourceware.org/ml/crossgcc/2011-02/msg00018.html
>
> I think it's not used ?for building a Linux/glibc toolchain.
> However, I did not test every example for ct-ng. I used ct-ng mainly for
> Linux/glibc tool chains.
> I doubt that binutils is really necessary, but Yann surely better
> knows what actually gets done with which part of binutils.
>
> Definitely binutils is *not* replacing anything of the host's cc toolchain,
> and it cannot do so.
>
>
> ---- ? gsed
> crosstool-NG requires sed to be 100% GNU.
> ---- ? gawk
> Don't know if it's really necessary. But installing it is easier
> than changing ct-ng, and does no harm.
>
> ---- ? gcc43 (only necessary for Leopard OSX 10.5)
> gcc4.0.1 on Darwin 10.5 is too old for some stuff.
> I do not have 10.5 anymore and I can't remember what it was.
>
> Installing a different gcc was NOT required and is NOT recommended on SL 10.6
> The latter NOT is why I said "Neither will *safely* work".
> To my knowledge there is no way to safely use a g++ from macports,
> at least in conjunction with c++ libs from a standard macports installation.
> That it apparently works for ct-ng it is due to the code being compiled / luck only.
> If by any chance macport's g++ pulls in some parts from libstdc++ from macports,
> your luck can run out very fast.
> In case you're interested in this problem, have a look here and into
> the link included in the post:
> http://www.mail-archive.com/macports-dev@lists.macosforge.org/msg14657.html
>
> ----
> In total, I tried to keep my Mac a Mac, minimally patching ct-ng where it was
> bound to GNU/Linux peculiarities, and install a minimal extra toolset with
> which I could build glibc-Linux-tool chains.
> And I did not question (except coreutils) what Yann requires in configure.
>
> And this (of course ;-) is how I'd like to keep the Mac port of ct-ng.
>
>>
>> Why don't you leave $cc tell you if it knows where to find that specific
>> library? Is it because the gcc on Darwin does not know about the option
>> -print-file-name ?
>>
>> Or why not:
>>> - ? ? ? ? ? ? ? ? ? ? ? $cc -print-file-name=lib${lib}.${ext} | grep -q /
>>> + ? ? ? ? ? ? ? ? ? ? ? $cc -L${LIBPATH} -print-file-name=lib${lib}.${ext} | grep -q /
>>> ? ? ? ? ? ? ? ? ? ? ? ?if [ $? -eq 0 ]; then
>>> - ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? echo "-l${lib}"
>>> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? echo "-L${LIBPATH} -l${lib}"
>>
>> In which case the -L${LIBPATH} should be passed from the caller to
>> check-lxdialog.sh, in kconfig/kconfig.mk:
>> ?ifeq ($(shell uname -s),Darwin)
>> ?LDFLAGS += -L/opt/local/lib
>> ?endif # Darwin
>> ?NCURSES_LDFLAGS = $(shell $(SHELL) $(check_lxdialog) -ldflags $(HOST_CC) $(LDFLAGS))
> Thanks for reviewing the changeset!
>
> On my system
> ls -l /opt/local/lib/libncu*
> gives
> /opt/local/lib/libncurses++.a
> /opt/local/lib/libncurses++w.a@ -> libncurses++.a
> /opt/local/lib/libncurses.5.dylib*
> /opt/local/lib/libncurses.a
> /opt/local/lib/libncurses.dylib@ -> libncurses.5.dylib
> /opt/local/lib/libncursesw.5.dylib@ -> libncurses.5.dylib
> /opt/local/lib/libncursesw.a@ -> libncurses.a
> /opt/local/lib/libncursesw.dylib@ -> libncurses.5.dylib
>
> but
> gcc -L/opt/local/lib -print-file-name=libncurses.dylib
> gives
> /usr/lib/libncurses.dylib
>
> I do not know this option well so I was stuck there and chose to kick that out.
> Bryan: What is the output on your system?
>
> Anyway, I'll try to figure out a minimal change in kconfig for the current version.
>
> Regards
> Titus
>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq