#triaging a missing macro on a module

1 messages · Page 1 of 1 (latest)

plain fable
#

Hi copium I've been porting the libressl/portable build script to zig, the script exposes 3 sublibraries:

  • libcrypto
  • libssl
  • libtls

after translating libcrypto's build script i got the following error roughly 3812 times:

~/.cache/zig/p/N-V-__8AALHw1AGnj1SDfks88vQlMBXp5AFwm7n8eZgIWKaP/crypto/crypto_init.c:144:15: error: a parameter list without types is only allowed in a function definition
LCRYPTO_ALIAS(OPENSSL_add_all_algorithms_conf);

this LCRYPTO_ALIAS macro is supposed to be used to expose symbols through a global-level asm snippet like this:

void
BUF_MEM_free(BUF_MEM *a)
{
        if (a == NULL)
                return;

        freezero(a->data, a->max);
        free(a);
}
LCRYPTO_ALIAS(BUF_MEM_free);

now, the macro itself is defined in crypto/hidden/crypto_namespace.h and that path is already in the includepaths of the module:

    const crypto_lazypath_prefix = dep.path("crypto");

    const crypto_includes: []const std.Build.LazyPath = &.{
...
        crypto_lazypath_prefix.path(b, "hidden"),
...
    };

    for (crypto_includes) |includepath|
        bundle.libs.crypto.root_module.addIncludePath(includepath);

my only thought was then that it could be a conditionally-declarated macro that was not being expanded due to not having defined a certain macro, the header source code will be included on the files of this message, the thing is that even when i forcefully define both LIBRESSL_NAMESPACE and LIBRESSL_CRYPTO_NAMESPACE (which would be dangerous because that's not done in crypto/CMakeLists.txt) the errors still appear

it would be useful to be able to check the preprocessed C code to see what the macro is expanding to i think

this is my first time doing something this big with the build system so im kinda lost in a lot of things, thanks in advance

📎 crypto_namespace.h
#

here are both libressl's and my naively-ported build script, it's a bit too big but the relevant part is setupCrypto, which is the place where i add the relevant files and includepaths to the libcrypto's root module

📎 build.zig 📎 CMakeLists.txt
pastel spindle
plain fable
#

yeah but from scratch

#

with the latest libressl release

pastel spindle
plain fable
#

huh that worked

#

thanks

#

i didnt expect the order to matter

pastel spindle
#

np

pastel spindle
# plain fable i didnt expect the order to matter

from allyourcodebase/libressl:

    // these are order-dependent and they have to go after the "hidden" directory
    // because the "openssl" include directory is masked inside the "hidden" directory
    // in the source tree. cool.
    source_header_prefix ++ "compat",
    source_header_prefix,
};
#

cool.

plain fable
#

lmao