# mkhash on FreeBSD



## balanga (Aug 3, 2018)

In case you were wondering how to run mkhash on FreeBSD ...

http://lists.infradead.org/pipermail/lede-bugs/2017-August/005303.html

Now can some remind me about how to apply patches? Haven't done this in over ten years.


----------



## ShelLuser (Aug 3, 2018)

`man patch`?  The patch(1) manualpage provides hands-on examples.


----------



## balanga (Aug 4, 2018)

ShelLuser said:


> `man patch`?  The patch(1) manualpage provides hands-on examples.


I've run `patch <patchfile -o newfile.c` but don't get a newfile.c. The patched file gets created but with some obscure name and gets placed in /tmp.


----------



## Phishfry (Aug 4, 2018)

patch(1)



> If    *patch* cannot find a place to install that hunk of the patch, it    will
> put the hunk out to a reject file,    which normally is the name of the out-
> put file plus ".rej".  (Note that the rejected hunk will come out in con-
> text diff form whether the    input patch was    a context diff or a normal


----------



## getopt (Aug 4, 2018)

balanga said:


> Now can some remind me about how to apply patches? Haven't done this in over ten years.


Never ask someome here "to remind" you. Managing your brain is not the service here. Clearly spoken it's your business. And if you got some dementia diagnosis, use some proper tools to organize your life. Not so long ago (your message counter just crossed 1.000 here) I gave you the hint to start learning on how to learn. That would widen your skills on how to get the information you need and improve understanding texts you initially did not understand. Looks like that hint still points to nowhere at your side. I'm trying not to get too rude as you might have some handicaps. If that is the case feel free to give me a PN. 

And yes, I can be helpful if I want to. You got that right. So I'm trying here to give you a hint. Do not expect to get solutions from me for what a manpage already shows you.

Now the patch(1) has a SYNOPSIS part which is essential. The synopsis tells you on how to properly write a command. Any command you type needs to be parsed first. If there occurs an error while parsing you need to lookup the SYNOPSIS section.

Patch has two alternatives in the SYNOPSIS section. Look on it! And now check what you tried which is a nice mix. Hint: it is about the use of "<".


----------



## balanga (Aug 7, 2018)

I have requested on the OpenWrt bugtracker that the available patch for mkhash.c be applied to the live version, which would allow the OpenWrt Build System to be installed on FreeBSD straight out of the box wothout any need for messing about with it. Apparently it needs a few votes for it to be applied, so if a few people register and vote for it, then it might get done.


----------



## balanga (Dec 4, 2021)

It seems that the OpenWrt patch for mkhash.c was never incorporated. This was the patch:-

```
--- mkhash.c.orig    2017-08-20 05:08:31.227317000 +0200
+++ mkhash.c    2017-08-20 05:06:46.000000000 +0200
@@ -78,8 +78,12 @@
  */
 
 
-
+#ifndef __FreeBSD__
 #include <endian.h>
+#else
+#include <sys/endian.h>
+#endif
+
 #include <stdio.h>
 #include <string.h>
 #include <stdint.h>
@@ -88,6 +92,7 @@
 
 #define ARRAY_SIZE(_n) (sizeof(_n) / sizeof((_n)[0]))
 
+#ifndef __FreeBSD__
 static void
 be32enc(void *buf, uint32_t u)
 {
@@ -124,6 +129,7 @@
 
     return (((uint32_t) be16dec(p)) << 16) | be16dec(p + 2);
 }
+#endif
 
 #define MD5_DIGEST_LENGTH    16
```

This seems to consist of two patches the first of which seems fine, but the second one, when applied to an updated mkhash.c creates the following:-

```
ifndef __FreeBSD__
static void
be32enc(void *buf, uint32_t u)
{
        uint8_t *p = buf;
       
        p[0] = ((uint8_t) ((u >> 24) & 0xff));
        p[1] = ((uint8_t) ((u >> 16) & 0xff));
        p[2] = ((uint8_t) ((u >> 8) & 0xff));
        p[3] = ((uint8_t) (u & 0xff));
}

static void
be64enc(void *buf, uint64_t u)
{
        uint8_t *p = buf;

        be32enc(p, ((uint32_t) (u >> 32)));
        be32enc(p + 4, ((uint32_t) (u & 0xffffffffULL)));
}


static uint16_t
be16dec(const void *buf)
{
        const uint8_t *p = buf;

        return (((uint16_t) p[0]) << 8) | p[1];
}

static uint32_t
be32dec(const void *buf)
{
        const uint8_t *p = buf;

        return (((uint32_t) be16dec(p)) << 16) | be16dec(p + 2);
}
#endif
```

This doesn't look right to me. Should the *#ifndef __FreeBSD__ *and *#endif* be placed somewhere else?
I may be completely wrong, in which could someone say if it does look ok?


----------



## SirDice (Dec 6, 2021)

Those functions already exist on FreeBSD. See byteorder(9).


----------

