[U-Boot] recent tools on FreeBSD

[Andreas Bießmann]

Hi,

On 06.02.15 20:56, Jeroen Hofstee wrote:
> Hello Simon, +Andreas,
> 
> On 06-02-15 04:05, Simon Glass wrote:
>> Hi Jeroen,
>>
>> On 5 February 2015 at 12:51, Jeroen Hofstee<jeroen at myspectrum.nl>  wrote:
>>> Hello Guilherme,
>>>
>>> Thanks for commenting on this,
>>>
>>> On 02/05/15 13:27, Guilherme Maciel Ferreira wrote:
>>>> Hi Jeroen,
>>>>
>>>> My apologies, I didn't test the tools on BSD. The answers are inline.
>>>>
>>>> Best regards,
>>>> Guilherme
>>>>
>>>> Am 04.02.2015 19:37 schrieb "Jeroen Hofstee"<jeroen at myspectrum.nl>:

> Regarding the linking problem, there is nothing special about FreeBSD ld,
> it just is based on a version which has no idea what INSERT BEFORE .data
> means.
> 
> there are several option I guess (not tested):
> 1) include a complete linker script so INSERT BEFORE .data is not needed
> 2) teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
> 3) don't use linker magic in tools (and use a linux box for sandbox, at
> least for now)
> 
> 1) sounds like a bad idea, the target/host might be any arch e.g.
> 2) won't magically fix problems as well, even if FreeBSD trunk can be
> teached to understand
> this, things will still be broken on releases. And u-boot tools work on
> more host systems,
> Andreas, can you check if Darwin is still able to compile tools from
> u-boot master?

unfortunately it does not.

---8<---
andreas at imac % git describe
v2015.04-rc1-4-g7f641d5
andreas at imac %
PATH=/Volumes/crosstool-ng/arm-unknown-linux-uclibcgnueabi/bin:$PATH
make CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- V=1
...
   gcc  -T ./tools/imagetool.lds -o tools/envcrc tools/envcrc.o
tools/lib/crc32.o tools/common/env_embedded.o tools/lib/sha1.o
ld: unknown option: -T
collect2: error: ld returned 1 exit status
make[1]: *** [tools/envcrc] Error 1
make: *** [tools] Error 2
andreas at imac % gcc --version
gcc (MacPorts gcc49 4.9.2_1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--->8---

> 3) the option I would be tempted to choose, just don't do linker magic
> for tools. This would
> make sure at least mkimage etc can be build everywhere. sandbox won't
> build, but as said
> it is already broken because of other issues. (and I doubt there is even
> an single user around
> besides me to even try to build sandbox on FreeBSD).
> 
> So as far as I am concerned we go for option 3.

+1

Dynamic list-sections is in general a good thing. But beside the linker
problem here we will get another problem on darwin hosts when we want to
read the sections. I added a patch to linux kernel to get around [1].

So I have another option here:

4) setup the lists sections in code, add the magic handling for Mach-O
binaries and remove the linker foo.

Best regards

Andreas Bießmann

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dd2a3acaecd7abb2d43b09a823cf2e4c967fa2ac