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: Need help with using crosstool to build toolchain for Au1550.


Hello Martin!
Hello All!

(re-sent, the previous one got HTML formatted by some ways unknown to me,
and rightfully rejected by sourceware.org. Sorry for the noise, Martin).

On Monday 07 July 2008 14:00:39 Martin Guy wrote:
> On 7/7/08, Martin Guy <martinwguy@yahoo.it> wrote:
> > The best answer is to remove bashisms
> There's a debian perl script checkbashisms which can help with this
> (if it matters).

Will try.

> I've run it over the scripts and there are a dozen or so trivial
> bashisms that are not necessary.

The only script that should be POSIXly correct is the configure script.
The others explictly require bash 3.0 or above. ./configure checks that
this is the case, and refuses to configure if not.

Unfortunately, there are certain constructs in the _build_ scripts that
require bashisms (eg. retrieving the exit status of any command in a pipe).

> Unfortunately it's not clear enough
> from the code what you are trying to achieve in certain places, like
>    . tsocks
> where tsocks is neither a shell function nor a local shell script.

Hmmm. I know there are almost no documentaion about the internals at the
moment. It is on my TODO, but it's a long road before I get anything
usable (and understandable!).

> Do you happen to know that it's implemented as a shell script on your
> system and think to save a millisecond?

If tsocks does not exist, '.' will yield an non-zero return code, and that
will be trapped by the 'set -E', the error "handler" will get executed, and
the build process will just stop right at that point.

Anyway, in this particular situation, there is a check for tsocks availablity
for each code path that uses tsocks:
  CT_HasOrAbort tsocks

Furthermore, the tsocks option in the ocnfiguration menu is marked as being
EXPERIMENTAL, and users selecting this option get warned if they read the
help entry:
  [--SNIP--]
  If you think you do not know what tsocks is, or how to configure it,
  chances are that you do not need to set this option.

And I don't buy arguments that states that users don't read the help! :-)

> Does tsocks need to set shell 
> variables in the same environment that are then picked up in the
> parent program? Does it matter if tsocks happens to use the same local
> variable name as CT and modifies them at random?

Variables that matters in crosstool-NG ought to be prefixed with "CT_".
And I do know what tsocks does: it sets LD_PRELOAD.

>    ${CT_PROXY_TYPE/socks}
> which doesn't conform to anything in the bash manual.

Yes it does. The manual explicitly states, in the section dealing with
"Parameter Expansion":
  If string is null, matches of pattern are deleted and
  the / following pattern may be omitted.

The bash manual lies on the table beside my bed, and I read a chapter every
evening, just before I switch the lights off... Just kidding! Hehe! :-)

> The bash 
> implementation I tried it on behaves the same as bash's
> ${CT_PROXY_TYPE/socks/} i.e., turn the first occurrence of "socks"
> into "" if it exists.

That's the intended behavior (see above).

> I'd code that some otherway, or at least say 
> what that piece of code is supposed to achieve.

Point taken! :-)

> Given puzzles like these I'm not confident to just fix them and send
> patches, regarding these constructs as obscure puzzles to bu guessed
> at rather than the lucid form of communication to other programmers
> that code should be :)

It would not come to my mind to look at Fortran code. I don't speak
Fortran.

My point is that to work with bash scripts, one must know bash scripting
(no offense meant!). :-) I do explicitly use bashisms, of which some I
consider as being features that fit my needs. The script are explicit
bash scripts, as they do use #!/bin/bash, and not the standard #!/bin/sh.
(One may object that bash may be in another place than /bin/bash).

On the other hand, you are right that the code lacks documentation, or
at least some comments near the tricky parts.

I will do a sanitising pass on the configure script, as this one shall be
POSIXly correct, and will try to add some comments in the build scripts,
where it is necessary, or change the code so it is more readable.

I'm planning a 1.2.0 release and the associated maintenance branch shortly,
and I don't know if I will have the time to investigate those issues prior
to releasing, though...

Please feel free to send patches commenting those parts you find tricky! :-)

> However, I attach the latest version of the checkbashisms perl script
> in case this is useful. The only thing you use that's hard to get
> round portably is "echo -n", though there is a portable hack defining
> a shell fn echo_n() in the good article on shell portability
> http://www.linux.com/articles/34658

Nice pointer! Instructive.

Regards, and many thanks again for your input!
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |   ^                |
| --==< °_° >==-- °------------.-------:  X  AGAINST      |  /e\  There is no  |
| http://ymorin.is-a-geek.org/ | * _ * | / \ HTML MAIL    |  """  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]