cURL / Mailing Lists / curl-library / Single Mail


Introducing cURL to another build/configure tool

From: Kevin \ <>
Date: Sat, 26 Mar 2016 00:01:05 +0100


For a couple of months I have worked on a build tool of my own. It has undergone a lot of different development versions and concepts, but I have finally reached one that I am extremely happy with, and which is also working out incredibly well!

One of the features I want to implement is a minimal package/dependency manager, allowing a project to depend on other projects or scripts for their build process. If you know NPM, then just think of a much slimmer version of that, but for native code instead, mostly.

So in order to get going on this, I need an HTTP client that would also support HTTPS so I could at least talk to the Github API. The first step for that was to port mbedTLS and MiniHTTP to the tool, but as it turns out, MiniHTTP isn’t exactly ready for HTTPS Github API :). That is when I decided to do a hefty gulp and take on the Autoconf based build and port it. And, believe it or not, it’s mostly ported!

You can see it here: <>

First off, excuse my silly/comical or nonsensical comments. For most of the time, I was sitting at home and in a really good mood due to how well the porting was actually going. Keep in mind, I spend merely a week on this port so far, and I managed to port almost the entire configure step.

Currently missing is to properly pick up the source files to compile into the static library - and aside from that, refine the way I currently build static libraries.

Now, to the problems.

If you hit CTRL+F or CMD+F when opening the link and type in TODO or Skip, you’ll realize just how much I could/did not port up to this point. Mainly:

- Libraries on different search paths (Heavily noticed in OpenSSL related checks)
- Structure members (IPv6, UNIX sockets)
- Host detection (Building a triple and not relying on the compile-time #define’s)
  * OS
  * Arch
  * Platform
- Various compiler checks (LCC, TCC, SunPro CC, …)
- OpenSSL libraries (The only one working is likely mbedTLS, and the others except for half of the OpenSSL checks are missing)
- LDAP (Because some checks I just didn’t understand)
- Testing specific linker/compiler flags and then translating them into the actual target
- curl tool
- Static/Shared checks and flags
- Cross-Compile checks
- A few Win32 related checks
- A few --with-* checks (libssh2, libnghttp2, …)

Aside from that, the other tests are pretty much implemented.

Most of the problems actually have to do with my own API. I need to work on these a lot still. But the greatest problem is checking for a function within a library. Currently, this is the source code emitted into a test file when checking for a function within a library:

// We first need to #def us a means of making a library name.
#ifdef _WIN32
   #include <windows.h>
   #define LIBNAME(l) TEXT("lib" l ".dll")
   #include <unistd.h>
   #include <dlfcn.h>
   #ifdef __APPLE__
       #define SHLIBEXT ".dylib"
       #define SHLIBEXT ".so"
   #define LIBNAME(l) "lib" l SHLIBEXT
// This is just a helper macro for stringing.
#define S(str) #str
int main(int argc, char** argv) {
   #ifndef _WIN32
       // Process tracker. It's value determines the result.
       int rt = 0;
       void* dh = dlopen(LIBNAME(S(${lib})), RTLD_LAZY);
       if(dh == NULL) {
           // 1: The library could not be resolved.
           rt = 1;
           goto end;
       void* symbol = dlsym(dh, "${func}");
       if(symbol == NULL) {
           // 2: No such symbol in this library. Trying again with prefix.
           rt = 2;
       } else {
           // 3: Symbol found.
           rt = 3;
           goto end;
       symbol = dlsym(dh, S(_) S(${func}));
       if(symbol == NULL) {
           // 4: Symbol not found, for real.
           rt = 4;
           goto end;
       } else {
           // 5: Symbol found with prefix.
           rt = 5;
           goto end;
           if(dh != NULL) { dlclose(dh); }
           return rt;
   #else // !defined(_WIN32)
       FARPROC* fh = GetProcAddress(
           GetModuleHandle(S(${lib}), S(${func}))
       if(fh == NULL) {
           // Windows: Library&Function not loadable.
           return 6;
       // 7: Loadable.
       return 7;

${lib} is replaced with a library name like "foo" where it’ll become either "foo" or "libfoo.dll". ${func} is the name of a function.

The problem: This works with libraries in the standard search path or in LD_LIBRARY_PATH or DYLD_LIBRARY_PATH. But when trying to test for a library in a different spot - for instance, someone specifies /opt/ssl as an OpenSSL prefix, it might be at /opt/ssl/lib/ - this method will fail, since linker flags do not affect the output’s runtime as for which paths it will search… Therefore I am stuck at this check currently, and this check is mandatory to perform the complete OpenSSL check, as well as the others.

The other check, checking for a struct member, is one I haven’t thought about before I came across the autoconf define within the CURL files. I need to develop such a check for my tool first.

I know this isn’t exactly a cURL question, but since it strongly relates to cURL, I decided to post an e-mail about my progress here. And if one of you has any idea for implementing some of the checks, even if just in theory, I’d be glad to hear back and contribute this as an alternative way to build libcurl. Although the IceTea build tool is still in development, I am planning on working on it pretty much prioritized in the coming weeks since my JavaScript development has grinded to a sudden halt (waiting for dependency authors to come out of vacation…).

By the way, where do you guys look up macro references for autoconf macros? I’d have a few I didn’t exactly understand...

Kind regards,

List admin:
Received on 2016-03-26