Developers' corner

On-box build succeeded with these settings in a config.mak:
Code:
CC = gcc
CFLAGS = -std=c99
# override defective library module
LDFLAGS = -l :sigset.o

prefix = /mod

NO_ICONV = 1
NO_IPV6 = 1

NO_PERL = 1
NO_TCLTK = 1

NO_CROSS_DIRECTORY_HARDLINKS = 1

INSTALL_STRIP = -s

NO_GETTEXT  = 1
NO_EXPAT  = 1

HAVE_SYNC_FILE_RANGE =
I had to create this somewhat hilarious /mod/include/gnu/lib-version.h
Code:
/* includer thinks it's GLIBC but it's not */
#ifdef __GLIBC__
#undef __GLIBC__
#endif
Then:
Code:
humax# pwd
/mod/src/git
humax# stat ./git
  File: `./git'
  Size: 7253005         Blocks: 14192      IO Block: 4096   regular file
Device: 801h/2049d      Inode: 6938607     Links: 137
Access: (0700/-rwx------)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-12-10 15:03:29.000000000 +0000
Modify: 2023-12-10 15:01:03.000000000 +0000
Change: 2023-12-10 15:01:15.000000000 +0000
 Birth: -
humax# ./git --version
git version 2.43.0
humax# ./git status -uno
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit (use -u to show untracked files)
humax#
Even after stripping the git executable is 6.5MB vs 4MB for x86 (this has been seen with other programs too). I wonder (again) if there's some build flag that would reduce the size.
 
Even after stripping the git executable is 6.5MB vs 4MB for x86 (this has been seen with other programs too). I wonder (again) if there's some build flag that would reduce the size.
Executables are always bloated on the MIPS cpu. It's because it doesn't implement register score boarding, with that technique on other cpus if an instruction uses a register before a previous instruction has generated the result in that register the cpu stalls. On the MIPS it's up to the compiler to find other instructions to put there, or if it can't find any (as is usual) the compiler has to put NOPs in. This was meant to be an optimisation but it means a) bloated binaries and b) when a new cpu takes less cycles to do something the code has to be re-compiled with a different target cpu to take any advantage of the faster instruction cycle timings.
 
With some more difficulty about actually getting the Curl stuff to compile (solved eventually by setting NO_CURL= on the make line, then hassles with locating libraries (solved with -rpath-link) I've built something that appears to work. It's in the Beta repository now.

The stupidity of autoconf/configure with testing stuff locally on the build machine to influence what does/doesn't get built for an unrelated target really is irritating.
Even after stripping the git executable is 6.5MB
-rwxr-xr-x 141 root root 5243816 Sun 10 Dec 2023 13:28:40 /mod/bin/git
includer thinks it's GLIBC but it's not
See previous comment about -D__FORCE_NOGLIBC

Code:
#!/bin/sh
ver=$(grep DEF_VER= GIT-VERSION-GEN |cut -dv -f2)
echo "$ver" >version
export CFLAGS="-D_FILE_OFFSET_BITS=64 -D__FORCE_NOGLIBC -std=gnu99 -I=$HOME/mod/include"
export LDFLAGS="-Wl,-R/mod/lib,-L$HOME/mod/lib,-rpath-link=$HOME/mod/lib"
./configure \
        --prefix=/mod \
        --host=mipsel-linux \
        --without-tcltk \
        --with-iconv=no \
        --with-curl="$HOME/mod" \
        --with-openssl="$HOME/mod/" \
        ac_cv_fread_reads_directories=no \
        ac_cv_snprintf_returns_bogus=no

make NO_CURL= CURL_LDFLAGS=-lcurl install
mipsel-linux-strip /mod/bin/* /mod/libexec/git-core/* 2>/dev/null
rsync -vrlptH /mod/* "humax:/mod/src/git_$ver""_mipsel/"
with just the one patch:
Code:
diff --git a/remote.c b/remote.c
index abb2482..065fb34 100644
--- a/remote.c
+++ b/remote.c
@@ -594,7 +594,7 @@ const char *pushremote_for_branch(struct branch *branch, int *explicit)
                                             branch, explicit);
 }
 
-static struct remote *remotes_remote_get(struct remote_state *remote_state,
+static inline struct remote *remotes_remote_get(struct remote_state *remote_state,
                                         const char *name);
 
 const char *remote_ref_for_branch(struct branch *branch, int for_push)
 
Last edited:
See previous comment about -D__FORCE_NOGLIBC

According to the features.h some builds break if __GLIBC__ isn't set (which that define forces) even if the interfaces expected from glibc are present. Apparently git isn't one.

I agree that MIPS may well be wordier than x86, but there's clearly some config difference between the CF repo gcc and the cross-compiler as shown by 6.5MB vs 4.8MB.
 
Struggling with REs again.
Given str1_str2_str3 I want to extract str3
Given str1_str2_str3_str4 I want to extract str3_str4
i.e. I want to strip str1_str2_ from the start of the given string and leave whatever is left, regardless of whether it contains an underscore.
In shell script, so trying with sed and failing - I just get str4 in the latter case. Struggling to ask big G the right question regarding lazy/greedy which I suspect might be the answer...
Code:
$ echo "xyz a1_b2_c3_d4"|sed -n "s/\(.*\) .*_.*_\(.*\)/\2 \1/p"
d4 xyz
 
Strip everything up to and including the first underscore, then feed the result into the same operation again.
 
A non-greedy match finds the shortest match rather than the longest. But if what is wanted is to strip any initial str1_str2_, then ^([^_]+_){2} matches that very thing, ie (start of string)(twice:(multiple non-_)_):
Code:
$ echo "a1_b2_c3"|sed -rn "s/^([^_]+_){2}//;p"
c3
$ echo "a1_b2_c3_d4"|sed -rn "s/^([^_]+_){2}//;p"
c3_d4
$

1. It's an extended RE so -r is needed for sed.

2. You might want to exclude other characters than _ from the str parts.
 
This seems to do what I want:
Code:
$ echo "xyz a1_b2_c3d4e5"  |sed -rn "s/^([^ ]+) ([^_]+_){2}(.*)/\3 \1/p"
c3d4e5 xyz
$ echo "xyz a1_b2_c3_d4e5" |sed -rn "s/^([^ ]+) ([^_]+_){2}(.*)/\3 \1/p"
c3_d4e5 xyz
$ echo "xyz a1_b2_c3_d4_e5"|sed -rn "s/^([^ ]+) ([^_]+_){2}(.*)/\3 \1/p"
c3_d4_e5 xyz
Thanks for the hints.
Might be a job for a one line Perl invocation.
You might be right but that's something I know nothing about and yet another world of pain.
 
Will there always be exactly a single space between the not-space group and the underscore-group?

Emacs and Netscape hacker (now SF nightspot proprietor) Jamie Zawinski said that someone who thinks regular expressions will solve a problem then has two problems. I would say that applies much more strongly to perl, but jwz seems to have been quite productive in it, even though he also wrote (what is clearly true):
[Perl] combines all the worst aspects of C and Lisp: a billion different sublanguages in one monolithic executable. It combines the power of C with the readability of PostScript.
 
You do need to be disciplined in Perl and write well commented code with meaningful variable and function names. If you do this you can have code that is as readable as C. If you don't you will likely have write-once-read-never code.
 
Will there always be exactly a single space between the not-space group and the underscore-group?
Probably, but it doesn't matter anyway as any more will get absorbed into the start of the string with underscores which is getting disposed of.
 
If you do this you can have code that is as readable as C. If you don't you will likely have write-once-read-never code.
Strange. A colleague of mine referred to C as write once read never code (or something very similar). Maybe because he didn't document it. You can write bad code in any language! (And I have done!)
 
Back
Top