[crosstool-ng] Menuconfig problems on Mac OS X

[Titus von Boxberg]

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.
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