make lto-compress.o error & build recovery question

Karim, Hassan hassan.karim at
Mon Feb 6 05:30:13 UTC 2017

Hmmm... so yet another reason NOT to use WSL. by the way, that symlink bug
is known but it is more specific to when I used the trailing slash in the
source directory. When I don't use the trailing slash, it works as expected.

Anywhoo... I think I will start over in the VM. Symlinks not working
properly. ugh!


*Hassan Karim, CISSP*
Comp Sci Ph.D. Student
Howard University
(202) 569-1012

On Mon, Feb 6, 2017 at 12:16 AM, Chris Johns <chrisj at> wrote:

> On 06/02/2017 15:54, Karim, Hassan wrote:
>> confirmed! It is very slow. The only exception is where we can use make
>> -j ... enabling multi threads/CPU's to get in on the action.
> I think more than 1 job with make now works on a recent MSYS2. To be
> honest I cannot remember if it is working. For a long time MSYS (MinGW32)
> had problems.
>> but besides that... I just encountered a bug with the Ubuntu on WSL...
>> symlinks to directories don't work as expected. The link apparently gets
>> created. One can CD into it. but what's inside of that linked directory
>> is ... ghostly. They act like recursive links to the same directory.
> Ouch.
> Are symlinks used in the RTEMS set builders?
> Yes but indirectly. For example
> urce-builder/tree/source-builder/config/gcc-common-1.cfg#n76. You could
> add __ln_s to as 'cp' to see if it works. I seem to remember
> from the distance past that MSYS basically did a copy rather than create an
> unsupported link.
> Also the RSB cannot control the contents of a tar file is expands and a
> tar file can contain a symlink. The same goes for a build system contained
> in a package.
> Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list