Re: Patches for crosscompiling on Mac OS X

[Geoffrey Lee <geoffl at gmail dot com>]

Hi all,

On 2010/11/01, at 15:43, Titus von Boxberg wrote:

> Yann, Geoffrey,
> 
> Am 01.11.2010 um 06:18 schrieb Geoffrey Lee:
> 
>>> 
>>> - ct-ng.install_headers.patch
>>> I do not understand what you mean by "non-latin characters". I do not know
>>> how MacOS-X works, but as long as your shell can access the /Volume/BLA
>>> mount point, then there shall be no reason crosstool-NG can't.
>>> Besides, I don't like to have to rely on packages cleaning up behind them,
>>> as the clean might not be absolutely complete.
>>> I guess that O= not working is just a sign of a more obscur problem.
>>> Lets try to find exactly what, and not try to mess things up.
>> 
>> Yes, I agree this is not a good fix and I understand the concern the problem of polluting ct-ng with hacks like these.
>> 
>> The problem appears that CURDIR is not being set properly if the path contains non-latin characters, and the O= option is used.  For me, non-latin in this case means a Japanese volume name. To my knowledge, names in HFS+ are UTF-8.  CURDIR is set internally by make, I am not sure what we can do here to workaround this.  The default make implementation in Mac OS X 10.6.x is GNU Make 3.81 by the way.
>> 
>> If it is interesting at all, my setup has a home partition mounted under /Volumes/<some non latin name> and /Users/user is a symlink to the home directory there.
>> 
>> e.g.
>> 
>> /Volumes/non-latin/xxxuser
>> 
>> /Users/xxxuser -> /Volumes/non-latin/xxxuser
> It's difficult to see how this could be a MacOS specific problem.
> To my knowledge you can nowadays have "non-latin" characters in a path
> on almost any OS.
> What do you mean by "non-latin", anyway?
> 


In this case I have a volume mounted under /Volumes with a Japanese name encoded in UTF-8.

For some reason instead of using /Users/username it seems to have walked the symlink and used /Volumes/<volname>/username instead and then it stopped working because CURDIR wasn't set.

It may be a problem with other operating systems too, I didn't mean to say that this was Mac OS X specific.

>> 
>>> 
>>> - glibc-2.9-rtld.patch
>>> This seems a patch against glibc, not against crosstool-NG... :-/
>>> Besides, it seems really hard to understand all its implications.
>>> Were did you get that from? Care to expand a bit on its implications?
>> 
>> 
>> Yes, this is a patch against glibc.  I should have made it clearer that it was a list of patches required to compile for Mac OS X which could include any of the input source packages as well.
>> 
>> I made the patch myself, the problem was during linking of rtld in glibc the build gave undefined references to__memcpy_chk, __memset_chk and there was a problem compiling with the memset.c file included from rtld-memset.c.  The glibc build system compiles certain files multiple times, in this case these certain files are compiled for the rtld module because the necessary define for the conditional compile was not present.
>> 
>> I cannot think of any adverse implications, it just means that the relevant symbols will be included for rtld.
>> 
>>> 
>>> - ct-ng-glibc.sh.patch
>>> There is already a sed handling in ./configure. To use a specific sed,
>>> just pass it: --with-sed=/path/to/gsed
>>> 
>> 
>> 
>> I think ct-ng already requires gsed during setup, is there a way we can propagate this configure option
>> upwards?  I think it would be best not to tie gsed to a particular path.
> PATH is modified to point first to a set of symbolic links to the required
> programs. So this gets propagated "upwards" for any script beyond the point
> where those links are created.
> 


Actually, I could not find any symbolic link to the sed I specified during ./configure of ct-ng.  If that's the case 
then something might have gone wrong during my installation.  I just had a look and it would appear paths.mk gets created with a sed variable pointing to what was specified during configure, is that what you meant?

In that case we can just do --with-sed=${sed} ?


 
> 
> 
>> 
>>> - ct-ng-gcc.sh.patch
>>> What does the MacOS-X' ld says to used static/shared libraries? GNU ld
>>> at least supports the equivalents:
>>> - for static: -Bstatic   -dn  -non_shared   -static
>>> - for shared: -Bdynamic  -dy  -call_shared
>>> If you can find a common option for both, then the better.
>>> 
>> 
>> 
>> Use -dynamic for dynamic and -static for static in ld(1).
>> 
>> As you have noted some of these problems are not with ct-ng per se.  I do not know what the normal workflow
>> for patches like these are, but I wanted to get them out first anyway.
>> 
>> By the way, I can re-do the patches, once we agree they can be applied to ct-ng and you need them to be formatted nicely by hg if it makes life easier.
> I did not have a look at the exact place you patched this, so just a general remark:
> Static linking of executables is unsupported under MacOS.
> That has been taken into account?
> 

I think it was a library, but yes, you are right, statically linking executables is not supported on Mac OS X.  
I did some further empirical testing and I think -static is not going to work in this case.



> Regards
> Titus
>  

	-gl



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