tcsh: Fix build of version 6.19.00

[thomas]

changes:

• added patch to disable builtin lscolors
• compile with -O1 to defeat gcc 5 optimizations that broke the executable

summary:
SRCURL[0]="http://ftp.funet.fi/pub/mirrors/ftp.astron.com/pub/tcsh/tcsh-${PKGVERSION}.tar.gz"
PATCHURL[0]='/src/mariux/patches/tcsh.nobuiltincolorls.diff'
mee_configure() {
CFLAGS=-O1 bee_configure
}
mee_install() {
bee_install
( cd ${D}/${BINDIR}; ln -sv tcsh csh )
( cd ${D}/${MANDIR}/man1; ln -sv tcsh.1 csh.1 )
}

[pmenzel]

Do you have more details please? Is there an upstream bug report?

[pmenzel]

1. What’s the summary good for?
2. Version 6.18 is still installed on deinemuddah. So the previous committed version never worked?

[thomas]

Zu 2. Noe, tot wie ein tuernagel :)

[donald]

Hmmm. Revision -0 without -O1 works for me ?

  buczek@geniux:~$ sudo bee list tcsh
  tcsh-6.19.00-0.x86_64
  buczek@geniux:~$ tcsh
  > exit
  buczek@geniux:~$ 

[thomas]

Donald, ich hatte das Problem sehr, sehr dirty gefixt.

[kreitler@torchwood:~]
#tcsh --version
tcsh 6.18.01 (Astron) 2012-02-14 (x86_64-unknown-linux) options wide,nls,dl,al,kan,rh,color,filec

[donald]

Right. "tcsh --version" hangs without -O0.

Reason: http://mx.gw.com/pipermail/tcsh-bugs/2015-May/000930.html

A fix is in the last message of the thread and has been accepted by Christos, the maintainer. But the thread is over one year old. Maybe it was forgotten? We should file a bug to https://bugs.gw.com/

[donald]

Perhaps use -DSYSMALLOC to avoid the problem? Untested.

[thomas]

Donald,

Also -DSYSMALLOC funktioniert (test: ./tcsh --version haengt nicht).
CFLAGS="-O2 -fno-optimize-strlen" ./configure liefert auch eine funktionable Version.

Eine Mail an Christos Zoulas marke:

Dear Christos,
when using default build options, we have problems compiling tcsh 6.19.00 witch gcc 5.3 under linux. The resulting binary hangs.
With approaches like "#define SYSMALLOC=1", "CFLAGS=-O1 ./configure", or "CFLAGS='-O2 -fno-optimize-strlen' ./configure" we obtain usable binaries ....

ist meines Erachtens unnoetig, da ich denke, dass dieser Fehler in 6.20 gefixt sein wird.
Der o.g. Thread ended am 28.5.2015, die 19er Relase ist vom 21.5.2015.

Wenn ich bedenke, dass das tcsh Update hauptsaechlich dazu diente eine Altlast mit 2 unterschiedlich verlinkten tcsh/csh Versionen aus dem System zu entfernen, finde ich diese 'exercise' hier zwar ganz schoen, aber auch ein wenig nutzlos.

[donald]

Dass das hier etwas länger dauert, hat mehrere Gründe.

• die aktuelle Version von tcsh ist zu der aktuellen Version von gcc inkompatibel. Dass man sich dann damit befassen muss, dafür kann keiner was. Das liegt in der Natur der Sache
• die Mühe, den bug zu identifizieren, habe ich mir freiwillig gemacht, weil ich das als kleine Gegenleistung dafür sehe, dass wir Software quasi geschenkt bekommen. Dass der Bug schon reported und vermutlich in der nächsten sowieso Release gefixt ist, weiß man ja auch erst hinterher. Sorry, dass dadurch etwas zusätzliche Noise entsteht, aber das kann man doch noch locker hinnehmen, oder nicht?
• du hast, wenn ich das richtig verstehe mit tcsh: Update to version 6.19.00, csh is now a symlink to tcsh #83 einen bee file gemerged, der nicht dem gebauten Package entspricht, da dieses irgendwie sehr, sehr dirty gefixt wurde. Passiert, überhaupt kein Problem, aber verkompliziert die Sache für diejenigen, die es verstehen wollen, eben zusätzlich.
• wenn hier, wie Paul immer wieder vorgeschlägt und vormacht, einzelne Commits mit nachvollziehbarere Begründung gewesen wären, hätte das sicher Rückfragen, Wartezeit und Noise hier gespart. Das könntest du halt anders machen, um das Geblubber kürzer zu halten.

Ein Nebeneffekt von letzterem wäre es, dass man es auch später noch nachvollziehen kann. Wenn da in drei Jahren wieder eine dran ist, schaut er kaum in die Diskussion beim Pull request und wundert wich vielleicht über dieses oder jenes ("warum haben wir das so gemacht?"). Git würde helfen, wenn die Info in den Commits wäre. zB neben der Idee von #83 (nämlich den csh symlink mit ins package zu nehmen und bei der Gelegenheit auf die letzte release zu gehen) , die in diesem Pull-Request nochmal richtig ohne dirty,dirty fix gemacht werden soll, gibt es hier ja weitere Änderungen. zB. Disable lscolore. Ich trau mich schon nicht mehr zu fragen, aber da hätte man ja sagen können, warum. Personal preference? Vor dir? Hat jemand gefragt? Oder hat es was mit dem Update zu tun um altes Verhalten wieder herzustellen? Und
( cd "${D}"/"${BEE_BINDIR}"; ln -sv tcsh csh ) zu ( cd ${D}/${BINDIR}; ln -sv tcsh csh ) ist das Kosmetik oder eine funktionale Änderung? Ist BEE_BINDIR oder BINDIR richtig? Ich weiß es nicht.

Ich glaube, das (zum Glück) so gut wie niemand mehr csh/tcsh einsetzt, deswegen spielt es vermutlich keine große Geige mehr. Ansonsten, da "-O0" eventuell schon spürbar an performance zerren könnte, wäre ein Fix mit weniger impact auch zu erwägen.

D.

[thomas]

Bei der Sache mit dem -O0 liegt ein Missverständnis vor, in #153 wird mit -O1 gebaut, da sind eventuelle Performanceverluste zu verschmerzen. Vom Ergebnis her macht es, auch gerade bei der tcsh, keinen großen Unterschied ob ich die Quelle fixe, oder ob ich den Übersetzter anders einstelle. Was letztendlich besser ist, kann ich nicht sagen.

Der 'dirty fix' der verunglückten #83 (6.19, nicht lauffähig) war ein Auspacken der 6.18er aus dem vorherigen Bee-Archiv und schnelles disten. (Der Fehler war mir morgens nach dem Dist aufgefallen, und lediglich Peter A. wurde genötigt ein kleines Script auf Bash umzuschreiben...)

Was die 'lscolors' angeht hätte ich freilich eine Bemerkung zufügen können (obwohl Bemerkungen auch Fragen nach sich ziehen können). Hier kommt sie -- beim Stöbern nach dem Fix für den Build ist mir aufgefallen, dass in den zwei Distros die ich zum checken ranziehe (Debian u. Slackware) die build_in_lscolors disabled bzw. kräftig gepatcht werden. Hmmm, tcsh ist alt, ls kann mittlerweile bunt, war wohl ein tcsh eigenes Feature. Braucht es 2 Farbumgebungen? Nein, also weg damit. -- Das ist also eine reine Bauchentscheidung gewesen, die wohl kaum Konsequenzen haben wird.

In der #83 liegt aber m.E. ein ganz anderer Hund begraben, und der konzentriert sich auf den wundersamen Übergang von ( cd "${D}"/"${BEE_BINDIR}"; ln -sv tcsh csh ) zu ( cd ${D}/${BINDIR}; ln -sv tcsh csh ). Das Quoten der Pfadvariablen geht auf einen Vorschlag (oder war es eine Bitte?) von Paul zurück. Nicht ganz nachvollziehbar, aber ich dachte 'Gut, um des lieben Friedens willen, du hast Recht, ich meine Ruhe'. Das stellte sich als Fehler heraus, wie eine anschließende kurze Diskussion zeigte.
In der 'Git-Conversation' waren dann noch verschiedene Vorschläge zu finden wie Symlinks auch gesetzt werden können (oder sollen? oder müssen? oder was?).
BEE_BINDIR war eine Missinterpretation meinerseits was die Namensgebung der Bee Variablen angeht, mit ein bisschen mehr Doku könnte man das m.E. verhindern.

Wie gesagt, ich bin nicht gegen Dokumentation und Nachvollziehbarkeit. Fraglich ist für mich nur die Art und Weise wie dieses Ziel erreicht werden soll. Ursprünglich lautete es mal 'wir gucken mal wie man es umsetzen kann' (oder so ähnlich). Ich denke, dass wir mittlerweile genug Beispiele und Szenarien durchgespielt haben, um daraus einen für alle akzeptablen Weg abzuleiten.

[donald]

My suggestion is in #184 with hopefully all the background info in the commits.

[donald]

obsoleted by #184