proxytunnel 1.9.0 Compile Fix for Mac OS-X

Need to run proxytunnel 1.9.0 on your OS-X Mavericks Mac? Well, just try it with the latest Brew installed and it breaks. Read on to see how to fix it!

proxytunnel Update: September, 2017

Just had a need for proxytunnel and to my surprise make didn’t work when I pulled down / extracted the code.

Why? Because Mac El Capitan Upgrade Removed openssl headers. The fix is simple:


cd /usr/local/include
ln -s ../opt/openssl/include/openssl .

That’s all – now continue ๐Ÿ™‚

For the Impatient

Don’t wanna read about my interesting adventures? I don’t blame you! Get the updated code using this link. Then rename the file to be proxytunnel-1.9.0-ABr.tgz and extract/build it normally.

The Problem

Here was the problem: I need to connect over HTTP proxy to a remote resource for SSH access. I use proxytunnel for this on my Linux and Windows boxes with no problem, and I want to do the same for my new Mac Mavericks OS-X.

Since I’m a total poser when it comes to Mac I jumped to this proxytunnel install page and followed the directions. (Keep in mind that I’m using brew.sh so I have my old friend wget installed.)


[...login as an Administrator...]
cd $HOME
mkdir -p proj/proxytunnel && cd proj/proxytunnel
wget http://downloads.sourceforge.net/proxytunnel/proxytunnel-1.9.0.tgz
tar xzf *tgz
cd proxytunnel-1.9.0
make

The above is Real Simple…and it should work. But it loses with this:

isgmj2chg3qp:proxytunnel-1.9.0 l.admin$ make
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o proxytunnel.o proxytunnel.c
In file included from proxytunnel.c:38:
./proxytunnel.h:35:8: error: expected parameter declarator
size_t strlcat(char *dst, const char *src, size_t siz);
       ^
/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'
  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))
                                           ^
/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'
#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)
                                                             ^
/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'
#    define _USE_FORTIFY_LEVEL 2

The root cause? Well, apparently with OSX Mavericks (10.9) some string manipulation functions are now macros instead of actual functions. Bummer. Because when you reference the name of the macro as the proxytunnel source files do, it *expands* to be whatever the macro was defined to be. Which breaks the pattern proxytunnel and others use to locally-define functions like strlcpy if they aren’t declared in system header files.

The Solution

I found the answer at this post on Kernel which indicated we have to modify source files. So…let’s modify away!

Define the Checks

The real problem is that we need to know if certain functions are defined as macros or not. So I created a new header file checkstr.h in the same folder as the proxytunnel source as follows:


/**
 * checkstr.h, ABr, 20141121
 * Account for change in OS-X where strlcat and friends are macros.
 */

#ifndef _PROXYTUNNEL_CHECKSTR_H
#define _PROXYTUNNEL_CHECKSTR_H

/* pattern is to see if the macro is defined; if not, see if the
   function is a macro. if it is, define the standard macro.
 */
#ifndef HAVE_STRLCAT
#ifdef strlcat
#define HAVE_STRLCAT
#else
#ifndef HAVE_STR_IS_SRC
size_t strlcat(char *dst, const char *src, size_t siz);
#endif
#endif
#endif

[...remainder cut...]
#endif

What I’m doing here is as follows:

  • #ifndef HAVE_STRLCAT – This macro is normally expected to be set if the strlcat function is already defined in the system. On my OS-X system, this guy is not being set…but on other systems it will be. So we start by looking for the macro and if we have it, do nothing else.
  • #ifdef strlcat – This is the “new” way that Mac OS-X 10.9 is handling the strlcat function (and its friends). The function is being defined a C-language macro; my #ifdef checks for this condition. If the function is indeed a macro then we fall through to the #define HAVE_STRLCAT line of code…all I’m doing there is defining the “standard” macro that – IMHO – should have been defined for us anyways.
  • #ifndef HAVE_STR_IS_SRC – OK, so I’m skipping a couple lines here but this article isn’t a primer on C language programming ๐Ÿ™‚ What I’m doing with this check is preserving the original proxytunnel code structure. I had to modify the base C source files all to #include checkstr.h and I want to be sure that the strlcat function is notdefined…cuz that’s the way the proxytunnel code was originally written. “Above all else, do no harm…” is the motto here…

So with my shiny new C header file in place, I simply modified the proxytunnel.h file to be as follows:


/* ABr, 20141121: comment these out
size_t strlcat(char *dst, const char *src, size_t siz);
size_t strlcpy(char *dst, const char *src, size_t siz);
size_t strzcat(char *dst, char *format, ...);
*/
/* ABr, 20141121: and replace with this */
#include "checkstr.h"

I had to do similar work with strlcat.c, strlcpy.c, and strzcat.c:


#include 

/* ABr, 20141121: extended checks for strlcat as macro */
#define HAVE_STR_IS_SRC
#include "checkstr.h"

#ifndef HAVE_STRLCAT

Notice in the above that the source file already has a check for the relevant macro HAVE_STRLCAT which is why I make sure I set it in my new header file. With the above change made to all three source files and the proxytunnel.h header file, I’m ready to build:


isgmj2chg3qp:proxytunnel-1.9.0 l.admin$ make
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o proxytunnel.o proxytunnel.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o base64.o base64.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o strlcpy.o strlcpy.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o strlcat.o strlcat.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o strzcat.o strzcat.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o setproctitle.o setproctitle.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o io.o io.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o http.o http.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o basicauth.o basicauth.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o readpassphrase.o readpassphrase.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o messages.o messages.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o cmdline.o cmdline.c
cc -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT -c -o ntlm.o ntlm.c
ntlm.c:259:3: warning: 'MD5_Init' is deprecated: first deprecated in OS X 10.7 [-Wdeprecated-declarations]
                MD5_Init( &tctx );
[...lots'o'warnings...]
/usr/include/openssl/ssl.h:1369:5: note: 'SSL_get_wfd' has been explicitly marked deprecated here
int     SSL_get_wfd(const SSL *s) DEPRECATED_IN_MAC_OS_X_VERSION_10_7_AND_LATER;
        ^
15 warnings generated.
cc -o proxytunnel -Wall -O2 -ggdb -DREV=0 -DHAVE_GETOPT_LONG -DUSE_SSL -DSETPROCTITLE -DSPT_TYPE=2 -DSO_REUSEPORT proxytunnel.o base64.o strlcpy.o strlcat.o strzcat.o setproctitle.o io.o http.o basicauth.o readpassphrase.o messages.o cmdline.o ntlm.o ptstream.o -lssl -lcrypto

As I note above, I do get a lot of warnings but that’s OK by me ๐Ÿ™‚ At least we build. And we run!

Get the tar file and use it above just as you would the normal one from the proxytunnel site. I’ve notified the maintainer of my change…maybe it will make it into the source ๐Ÿ™‚

Happy Computing!

Team-oriented systems mentor with deep knowledge of numerous software methodologies, technologies, languages, and operating systems. Excited about turning emerging technology into working production-ready systems. Focused on moving software teams to a higher level of world-class application development. Specialties:Software analysis and development...Product management through the entire lifecycle...Discrete product integration specialist!

Leave a Reply

Your email address will not be published. Required fields are marked *

*