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


Hello Yann, all -


On 2010/11/01, at 8:53, Yann E. MORIN wrote:

> Geoffrey, All,
> 
> On Friday 29 October 2010 03:07:50 Geoffrey Lee wrote:
>> I'm building a cross toolchain for Linux/x86-64 on Mac OS X with ct-ng 1.8.1.
>> I've needed to patch some files to make it compile, which I have attached.
> 
> While I appreciate the effort, I have some concerns with your patches.
> 
> First and foremost, they are really difficult to apply, as they are not
> correctly prepared. You should use Mercurial to prepare your patches and
> send them. At the very least, it should be possible to apply those patches
> using "patch -p1".
> 
> Second, because your patches are inter-mixed with the body parts, replying
> to the whole message is not easy.
> 

In my haste to get the patches out I had forgotten to rediff them from the top of the source tree.  I had also 
forgotten the Apple Mailer will place the patches inline instead of at the end.  I will keep those in mind the
next time I send any patches.

I have included the responses to your comments below.

> Anyway, here are my comments on the patches:
> 
> - 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

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


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

> Regards,
> Yann E. MORIN.
> 


	-gl

> -- 
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
> 
> 


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