chmod -R u+w .build/src EACH TIME?????

Thu Mar 3 22:32:00 GMT 2011

Andy, All,

On Thursday 03 March 2011 20:34:29 ANDY KENNEDY wrote:
> > From: Yann E. MORIN []
> > Onlt five of them. It took only a few minutes to do a chmod in all
> > 5 of them, so no big deal...

> I'm confused.  I must really be misreading what you wrote.  I thought
> that
> it was an issue of the unpacks unpack into other directories besides
> their
> own?  Like autoconf-2.65 unpacks into automake a subdirectory/files to
> identify autoconf-2.65.  I must really have read into what you wrote.

OK, I was not clear either. Sorry for the confusion...

When I noticed (due to an error) that some packages were extracting RO
files, the easiest solution that came to mind at the time was to run a
chmod just after extracting the tarball.

Then, I thought that I did not know in advance what packages would ship
RO files, so I thought that to avoid any issue in the future, it would
be necessary to systematically run the chmod, on every packages.

But on the other hand, I also thought that manually inserting a chmod
in every packages was stupid, when I could use the CT_Extract helper
function to do it, as all packages call it to extract their tarballs.

So, the place where to run the chmod was found: the CT_Extract helper.

Then came the issue with tarballs which names are not always tied to
the name of the directory they extract, and the CWD where it should
be extracted. Let's take my previous table again, and lets add CWD in
there (remember, I explain what is *currently* happening):

For gcc 4.3.2:
  tarball basename  : gcc-4.3.2
  CWD               : ${CT_SRC_DIR}/
  extracted dir     : ${CT_SRC_DIR}/gcc-4.3.2/

For Cloog/PPL 0.15.3:
  tarball basename  : cloog-ppl-0.15.3
  CWD               : ${CT_SRC_DIR}/
  extracted dir     : ${CT_SRC_DIR}/cloog-ppl/

So, looking at those two packages, we see we can't deduce the directory
name by just looking at the tarball basename.

So, the solution to force the directory name, and then strip components is
OK. We can have sane, canonical directory names. But I did not think of
that at the time. Too bad...

But lets take a second look...

For glibc 2.9:
  tarball basename  : glibc-2.9
  CWD               : ${CT_SRC_DIR}/
  extracted dir     : ${CT_SRC_DIR}/glibc-2.9/

For glibc 2.9 ports add-on:
  tarball basename        : glibc-ports-2.9
  CWD                     : ${CT_SRC_DIR}/
  extracted dir           : ${CT_SRC_DIR}/glibc-ports-2.9/
  or (depends on version) : ${CT_SRC_DIR}/ports/

But for glibc to find and use them, the add-ons shall be below the glibc
directory, either one of (missing one symlinked to existing one):

That also applies to other glibc add-ons, and to other C libraries add-ons
also. So we can't cd ${CT_SRC_DIR} before extracting add-ons. Detecting
that we are extracting add-ons in the helper function is doomed to fail
(it would have to _know_ about the add-ons stuff, and so would not be

Instead, we rely on the caller to tell CT_Extract that the CWD is already
set to the proper place to extract the tarball. So what actually happens is:

For glibc 2.9 ports add-on:
  tarball basename        : glibc-ports-2.9
  CWD                     : ${CT_SRC_DIR}/glibc-2.9/ (untouched by helper)
  extracted dir           : ${CT_SRC_DIR}/glibc-2.9/glibc-ports-2.9/
  or (depends on version) : ${CT_SRC_DIR}/glibc-2.9/ports/

Here, we can see that we do not know what directory we should chmod, either.

Then, once a package is extracted, we may have to apply patches. Some
packages even re-run autoreconf et al. Crosstool-NG patches a package
right after it has been extracted:
  extract package foo
  patch package foo
  extract package bar
  patch package bar
  autoreconf package bar
  and so on...

So we have to ensure that between extract and patch, the files are RW.

What options were left, then? We have to find a place that, when recursively
chmoded, would effectively chmod all the package's extracted files, without
having the adverse effect of also chmoding other files (if the user did
chmod u-w on his #{HOME}, who the heck are we to change that back?).

The only place we know for sure that contains our extracted directories is
of course our top-level source dir ${CT_SRC_DIR}. Doing the chmod in there
would ensure that all extracted files would be chmoded. The adverse effect
being that even pre-chmoded files would be chmoded again and again until
all packages were extracted.

At the time, this option seemed more than reasonable to me. You proved that
I was wrong. That's not a problem. :-)

Now, assuming that the chmod has to be done for _every_ packages turns out
to be totally over-kill, even if only chmoding the current package's files.
We only have 5 offending packages, lets have them cleanup their mess...

Of course, if we wanted to do it unconditionnally, then a solution like
your proposal would be nice to have (see below).

> > > See, we take the Doc's Delorean, hit 88MPH and go back in time
> > > precisely one minute.
> > Hehe... 88MPH.. Hehe! :-)
> Sorry, I really enjoyed the 80s.

So did I! :-)

> > OK, so you mean every tarball should be extracted into its own
> intermediary
> > directory, so we'd get:
> >   ${CT_SRC_DIR}/glibc/glibc-2.9/{all,glibc,files,here}
> >                /gcc/gcc-4.3.2/{all,gcc,files,here}
> No, it would be:
> ${CT_SRC_DIR}/glibc/{all,glibc,files,here}
>              /gcc/{all,gcc,files,here}

Ah, but that would not work. As you can build more than one toolchain
from the same working direcotry, and each toolchain might use different
versions of, say, gcc, you'd mess up.

But then, doing smthg like:

  if nochdir; then
    pushd .  # For symetry!
    mkdir "${CT_SRC_DIR}/${basename}"
    pushd "${CT_SRC_DIR}/${basename}"
  tar x --strip-components=1 -j -f "${tarball}"
  chmod -R u+w .

would most probably do the trick with a few adjustements, I think.

> Though, if that seems foreign to you and you don't like it (and this is
> ultimately your project) you have the final say.

Hmmm. I like being chalenged. I can't test in every conditions, and
something that works for me, and which I did not think would be a serious
issue, could turn to be a nightmare for someone. Sometime, it turns out
the way I choose was the best one, sometime it turns out a better way is
found  (best and better, as when balancing pros and cons, simplicity vs.
efficacity, pragmatism vs. ideology...)

And although I am maintaining the stuff, it would not be good that I would
reject the opinion of the users. If there is an issue, and it is a real
issue (ie. poor performance, bad behavior, stupid code...), then I'd like
the case to be solved. At least with an explanation of the case, at best
with a fix (code and/or doc).

Yann E. MORIN.

|  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  |
| | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

For unsubscribe information see

More information about the crossgcc mailing list