This one lacks -a but is simpler to port than the (e)glibc one,
and should be way enough for usage patterns like counting CPUs,
cf. https://gist.github.com/jj1bdx/5746298
TODO: Handle message files?
TODO: Install manpage?
CreateSubRequest() could still return an error and break out of the
while loop without exiting the outer for loop.
Instead we reset the error code before entering the for loop.
This reverts the extra for loop condition from
"do_iterative_fd_io_iterate(): Support sparse files".
When reading a file with more than 8 block_runs, get_vecs() would
return B_BUFFER_OVERFLOW which would never create any subrequest due
to the test on error == B_OK on the loop, but instead just fail.
Except for the get_vecs() return code, where it is not wanted,
the test made no sense as all other assignments are tested directly
or passed around with break.
Works for me but I don't guarantee it's completely correct.
When asked to strip binaries when copying to containers we now
strip to a temporary file, copy over resources to it, copy it
to the container, then copy the attributes from the original
source.
This should allow stripping binaries while preserving attributes
and resources even when copying to images.
We now only attempt to strip binaries, by detecting the
LINKFLAGS variable on the targets.
CopySetHaikuRevision now also forwards LINKFLAGS
to revisioned binaries.
Introduce separate AppendToContainerCopyFilesScriptStripFile actions
which are used for copying and stripping, and avoids many useless
shell tests.
When asked to strip binaries, they are detected and handled
individually for simplicity.
Note we still don't keep resources and attributes when stripping.
This makes it fit again.
We can't reference in BuildSetup a variable set with the other
ones in KernelArchitectureSetup since the rule is invoked later.
Currently only needed for boot floppy on some platforms.
Disabled for now.
Note we do not have a mean of knowing which file is a binary
or not so we just try to strip, and silently continue when
strip fails (like on the kernel settings file).
Also note strip actually replaces the file, which means it looses
both the resources and attributes, which shouldn't be a problem
for the boot floppy drivers archive, but is not wanted for other
images, so it's not usable elsewhere as such. Patch wanted.
Instead of listing all the objects we want from the libgcc archive
we just make a copy of it and remove those we don't want, and link
to it.
This should allow returning MAXLINE in jam to a sane value.
Looks like I was too quick on previous commit.
It seems -pthread is actually not that much needed on Linux though...
although the manpage says "compile and link with -pthread". Go figure.
Now dlopen() uses RTLD_LAZY | RTLD_LOCAL for Linux, which seems
to work here.
Declare a HOST_PTHREAD_LINKFLAGS variable to hold the flags
required to link with pthreads, and use it for the solver addon.
Works on GNU/Linux, please test and fix for other platforms.
Latest gcc converts the old ones to the new ones anyway...
including when passing to gas, which of course is not new enough,
so we have to also force gcc to pass the old one around in one case.
Since the PM merge we now have way too many targets,
here jam clean just fails in execve() due to too long arguments.
jam clean is now very verbose but at least it works.
Another option could be to override the Clean rule itself
to clean in batch by splitting the list...
Patches welcome.
jam fails in execve() trying to run the command due to
a too large arguments list because of the many objects in libgcc.
We split them into two intermediate objects,
then we link them to libroot.
Since both platforms can boot the same kernel we must accept either
arg, so we make sure they are identical for now.
TODO: use a union or KMessage maybe?
Unlike Classic PPC, Book-E CPUs do not have hardware page-table walk,
rather only a limited set of software-managed TLBs. Also, translation
is never disabled even when page-faulting.
The Linux Book-E port pins part of the RAM in one or more TLBs, and
allocates kernel memory from it for the kernel itself and exception
vectors, as well as page tables.
cf. http://kernel.org/doc/ols/2003/ols2003-pages-340-350.pdf
We take a similar approach, but instead of using a tree-like page
directory we reserve a large part of this mapped range for an
hashed page table similar to the Classic one, to later allow
factoring code out. The kernel and boot modules will also be
allocated there, and the rest should be used as SLAB areas.
Note doing so will not allow implementing proper permissions for
the areas allocated there since they are all handled by a single TLB.
Also note Book-E does not standardize the MMU implementation itself.
For now only AMCC440 type MMU is supported. This will need to be
cleaned up later on.
The size variable at this point is actually a page count.
The test should never be true anyway though. Maybe we should use a
pages variable for clarity?
François Revol