Re: Release management: how do you update the libtool version information?
tis 2023-03-07 klockan 14:20 +0100 skrev Bruno Haible: > Simon Josefsson wrote: > > Consider adjusting your habit to update the libtool version > > directly > > AFTER a release instead. I put the following in cfg.mk to make > > sure I > > don't forget this: > > > > sc_libtool_version_bump: > > @git diff v$(PREV_VERSION).. | grep '^+AC_SUBST(LT' > > > /dev/null > > > > Of course, you still have to bump it if you make any API/ABI > > changes, > > Is a maintainer not _more_ likely to forget about the libtool > versioning, when he has a rule like that, that makes him think "I'm > already on the safe side, since I have done it already"? Yes, maybe -- although but approaches are fragile and depend on maintainer attention, so they are both sub-optimal. I have used libabigail's abidiff to find API/ABI differences with good results -- however, I don't know of a good way to check libtool shared library versionining information against it. Some brain storming how it would work: 1) On 'make check' (or distcheck, or similar), do a abidiff of the newly built library against a previously stored *.abi file and exit with failure on differences (or if no file exists). 2) Add README notes to instruct maintainers to add known good new *.abi files named like libfoo-x86_64-1-2-3.abi where 1-2-3 is the libtool- version when any API/ABI-changes are made, or when libtool version is bumped. Maybe the '-3' part shouldn't be part of the filename. 3) for bonus points: Add some consistency check that the diff follows libtool-semantics for ADDED vs MODIFIED ABI differences. Not all API/ABI changes results in abidiff-changes, though, although these days I think it is generally considered a bad idea to bump libtool shared library version for anything but pure symbol changes. For semantical changes, introduce new APIs and deprecate the old ones instead. /Simon signature.asc Description: This is a digitally signed message part
Re: GNU lib - z/OS thread related fix
Hi, > I am porting m4 to z/OS and came across following compilation error related > to gnulib: > > glthread/thread.c:206:1: error: unknown type name 'gl_thread_t'; did you mean > 'pthread_t'? First of all, I need to understand the configuration. Please, can you attach - the config.cache file generated by './configure -C' - the config.status file - the config.h file Also, did you specify a configure option --enable-threads=... [1] ? If so, what are the corresponding configuration files when you don't specify an --enable-threads=... option? Bruno [1] https://www.gnu.org/software/gnulib/manual/html_node/Choosing-a-multithreading-API.html
GNU lib - z/OS thread related fix
Hi Team,
I am porting m4 to z/OS and came across following compilation error related to
gnulib:
glthread/thread.c:206:1: error: unknown type name 'gl_thread_t'; did you mean
'pthread_t'?
gl_thread_t
^~~
pthread_t
/usr/include/le/sys/types.h:288:13: note: 'pthread_t' declared here
} pthread_t;
^
glthread/thread.c:209:3: error: unknown type name 'gl_thread_t'; did you mean
'pthread_t'?
gl_thread_t thread;
^~~
pthread_t
/usr/include/le/sys/types.h:288:13: note: 'pthread_t' declared here
} pthread_t;
^
glthread/thread.c:212:9: warning: implicit declaration of function
'glthread_create' is invalid in C99 [-Wimplicit-function-declaration]
ret = glthread_create (, func, arg);
The compile command used is:
source='glthread/thread.c' object='glthread/thread.o' libtool=no \
DEPDIR=.deps depmode=hp2 /bin/sh ../build-aux/depcomp \
xlclang -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I../lib -DIN_M4_GNULIB_TESTS=1 -I.
-I. -I.. -I./.. -I../lib -I./../lib -DNSIG=42 -D_XOPEN_SOURCE=600 -D_ALL_SOURCE
-D_OPEN_SYS_FILE_EXT=1 -D_AE_BIMODAL=1 -D_ENHANCED_ASCII_EXT=0x
-qascii -std=gnu11 -qnocsect -qenum=int -qgonumber -O3 -qnose -std=c11
-fgnu89-inline
-I/home/haritha/code/m4port/m4/lib,/home/haritha/code/m4port/patches/PR1/include,/usr/include/le
-c -o glthread/thread.o glthread/thread.c
The above error got fixed when I moved the below code under #if USE_ISOC_THREADS
gl_thread_t
gl_thread_create (void *(*func) (void *arg), void *arg)
{
gl_thread_t thread;
int ret;
ret = glthread_create (, func, arg);
if (ret != 0)
abort ();
return thread;
}
I have attached the file with git diff for reference: thread.c.patch
I would like to upstream these changes. Please let me know if you have any
concerns or questions.
Regards
Haritha
thread.c.patch
Description: thread.c.patch
Re: Release management: how do you update the libtool version information?
Simon Josefsson wrote: > Consider adjusting your habit to update the libtool version directly > AFTER a release instead. I put the following in cfg.mk to make sure I > don't forget this: > > sc_libtool_version_bump: > @git diff v$(PREV_VERSION).. | grep '^+AC_SUBST(LT' > /dev/null > > Of course, you still have to bump it if you make any API/ABI changes, Is a maintainer not _more_ likely to forget about the libtool versioning, when he has a rule like that, that makes him think "I'm already on the safe side, since I have done it already"? Bruno
Re: Release management: how do you update the libtool version information?
Vivien Kraus writes: > Dear gnulib people, > > How do you manage the libtool version information for a library using > gnulib? For now, I have it written down explicitly in configure.ac. > Unfortunately, this requires a new commit to bump the numbers before > each release. > > Gnulib provides a script to help update the libtool version > information. Is there a way to involve that script in the "make > release-commit" invocation? It is a little awkward to create a commit > just to bump the libtool version information, or to squash it with the > commit created by "make release-commit". > > My current solution involves a bit of cheating: fix do-release-commit- > and-tag not to complain about a dirty tree, and have the libtool update > already staged when running make release-commit. > > Am I missing something here? How do you update the libtool version > information? Consider adjusting your habit to update the libtool version directly AFTER a release instead. I put the following in cfg.mk to make sure I don't forget this: sc_libtool_version_bump: @git diff v$(PREV_VERSION).. | grep '^+AC_SUBST(LT' > /dev/null Of course, you still have to bump it if you make any API/ABI changes, but with this approach, you don't need to bump it just before each release. And you can have the latest released version installed and co-exist nicely with the development branch too. /Simon signature.asc Description: PGP signature
