0

I need to patch libidn2 on Solaris. libidn2 was fetched from GNU's website with wget. Its not provided by Sun and its not in source control.

The library does not use glibc, and it does not have the function error (int status, int errnum, const char *format, ...). I made a copy of the original source file and I have a diff with a similar function:

solaris:libidn2-0.16$ diff -u src/idn2.c.bu src/idn2.c --- src/idn2.c.bu 2017-03-29 00:20:08.621934160 -0400 +++ src/idn2.c 2017-03-29 01:25:12.488402745 -0400 @@ -31,7 +31,9 @@ #include <unistr.h> /* Gnulib headers. */ +#ifndef __sun__ #include "error.h" +#endif #include "gettext.h" #define _(String) dgettext (PACKAGE, String) #include "progname.h" @@ -48,6 +50,18 @@ year. */ "Copyright %s %d Simon Josefsson."; +#if defined(__sun__) +static void +error (int status, int errnum, const char *format, ...) +{ + va_list args; + va_start(args, format); + vfprintf(stderr, format, args); + va_end(args); + exit(status); +} +#endif + static void usage (int status) {

I've been reading through the diff(1) and patch(1) man pages, but I'm not quite getting what needs to be done. I don't believe I've found a discussion of the task (maybe I am not seeing the forest through the trees).

My question is, how can I turn this into a free standing patch? That is, how can I turn it into something to apply after a fresh download and unpack of libidn2?

Improve this question

2 Answers 2

Reset to default
3

This might not be the correct answer, but the quote won't fit into a comment, and my experience with patch is that the output from diff is the "freestanding patch".

You can run patch --dry-run < your.diff.output from most likely the base directory of the expanded libidn2 source tarball to see what would happen if you apply your diff output with patch.

In my installed copy of Solaris 11, patch appears to be GNU patch as it has the --dry-run option. The Solaris 11.2 patch man page has this excerpt for creating patches:

NOTES FOR PATCH SENDERS

There are several things you should bear in mind if you are going to be sending out patches.

Create your patch systematically. A good method is the command diff -Naur old new where old and new identify the old and new directories. The names old and new should not contain any slashes. The diff command's headers should have dates and times in Universal Time using traditional Unix format, so that patch recipients can use the -Z or --set-utc option. Here is an example command, using Bourne shell syn- tax:

 LC_ALL=C TZ=UTC0 diff -Naur gcc-2.7 gcc-2.8

Tell your recipients how to apply the patch by telling them which directory to cd to, and which patch options to use. The option string -Np1 is recommended. Test your procedure by pretending to be a recipient and applying your patch to a copy of the original files.

...

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

-2

This sounds like an XY problem. Your core problem is "currently I am applying a patch to the libidn2 source which I want to redo later for future releases of libidn2", right? This is exactly what you want to use source code control for! Just because the upstream source is not fetched from a source code control repository, it does not mean that you cannot put into one yourself:

$ mkdir libidn2-source; cd libidn2-source $ git init $ git checkout -b upstream $ wget https://alpha.gnu.org/gnu/libidn/libidn2-0.16.tar.gz $ tar zxvf libidn2-0.16.tar.gz && rm libidn2-0.16.tar.gz $ git add . $ git commit -m "Upstream libidn2-0.16.tar.gz" $ git checkout -b downstream $ cp /the/file/in/the/question/src/idn2.c src/idn2.c $ git add src/idn2.c $ git commit -m "Added sun specific error fallback function" # In the future... $ git checkout upstream $ wget https://alpha.gnu.org/gnu/libidn/libidn2-latestgreatest.tar.gz $ tar zxvf libidn2-latestgreatest.tar.gz && rm libidn2-latestgreatest.tar.gz $ git add . $ git commit -m "Upstream libidn2-latestgreatest.tar.gz" # Now for the "apply after a fresh download and unpack of libidn2" part: $ git rebase upstream downstream

Notice the lack of any keep track of and update free standing patch file here.

The source seems to be available in a git repo, so you might just clone that instead of downloading and checking in tar files, but the rebase part will be exactly the same.

Improve this answer

2 Comments

Thanks. Checking out from Git is not in the workflow. in fact, the script is intended to be run on CentOS 5 and Fedora 10. The script installs Git on machines that don't have it. Once the initial script was written it was pointed towards Solaris. Oracle provides a very old Git (Solaris 11) or no Git at all (Solaris 10). Oracle charges folks to allow access to their updated Git.
But git is still the answer to "how can I turn this into a free standing patch?". You do not need to have git installed on the Solaris machines, just store it on one of the Centos/Fedora machines and then when you need the patch for one of the Solaris machines you run git format-patch upstream downstream and it will create an up to date, free standing patch which you than can apply with the patch(1) program.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.