This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patches for crosscompiling on Mac OS X


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?

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



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

Regards
Titus


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]