bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New gnulib user !


From: Vivien Kraus
Subject: New gnulib user !
Date: Wed, 29 Jun 2022 23:34:48 +0200
User-agent: Evolution 3.42.1

Dear gnulib people,

I have recently learnt how to use gnulib, and I have to say, it is
pretty impressive. It provides some very useful functions, and it
integrates smoothly with my existing workflows, including git and, more
surprisingly, guix.

I am still discovering the modules, but have already set up the
bootstrap script, the relocatable program and libraries, and I finally
get to enjoy (relatively) easy mingw cross-compilation.

I noticed these things that are less perfect though:
- The bootstrap script tends to rename what I expect to be
"lib/libgnu.[l]a" to "lib/libfoo.[l]a" (if foo is the package name),
which is very confusing, especially if you already have a library with
the same name elsewhere in your project. It can be configured, which I
did.
- The bootstrap script wants to download the PO files from the
translation project. From what I understand, it is a private audience
website. When I first discovered the bootstrap script, I got the
impression that I was expected to put my translations there. But I
don’t think I can register my project to the website, which is
disappointing.
- If I want a libgnu for a library and another libgnu for a program, I
must have 2 bootstrap scripts with different configurations, which
means that translations are downloaded twice, the gnulib submodule is
updated twice, and autoreconf steps are done twice. Is this normal? I
think it can’t hurt, but I’m not sure I understand everything.
- The library function export visibility trick is great, but the manual
suggests to augment it with dllimport/export for MSVC:

#if BUILDING_LIBFOO && HAVE_VISIBILITY
#define LIBFOO_DLL_EXPORTED __attribute__((__visibility__("default")))
#elif BUILDING_LIBFOO && defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllexport)
#elif defined _MSC_VER
#define LIBFOO_DLL_EXPORTED __declspec(dllimport)
#else
#define LIBFOO_DLL_EXPORTED
#endif

However, using this as-is breaks for mingw (HAVE_VISIBILITY is 0 and
_MSC_VER is not defined, so all symbols are exported, which means a
possible collision with gnulib functions used in both libfoo and a
program linked to libfoo). Maybe the manual should suggest to extend
the MSVC check to mingw as well? That’s what I did in my project.

Anyway, that’s not really a bug report, but I only found this address,
and I wanted to point to the things that puzzled me about your
beautiful library.

Best regards,

Vivien



reply via email to

[Prev in Thread] Current Thread [Next in Thread]