build: lib target now builds a shared library. #662
Conversation
|
I've used this successfully to build |
|
See https://gitlab.com/jgemu/bsnes/-/merge_requests/429 for an example of how this can be used. |
|
@LIJI32 Something this would require is caring about the API stability in the future and updating versioned libraries accordingly, I'm not sure your feelings on that. Personally I would like better handling of the sameboy library, but only if you are also committed to the idea. |
|
I've been gradually and intentionally stabilizing the API slowly the last few years, which is why |
Apteryks
force-pushed
the
build-and-install-shared-lib
branch
3 times, most recently
from
87f0c7b
to
20ddb7f
Compare
|
Here's what the latest revision produces on my side: If I use LIBRARY=static, I get the .a instead of the .so, if I use LIBRARY=1, I get both. |
When the 'LIBRARY' variable is set, the libraries are also now installed along the headers and a newly introduced pkg-config file. * Makefile (LT_CURRENT, LT_REVISION, LT_AGE, LT_VERSION_INFO): New variables. (DEFAULT) [LIBRARY]: Add lib to it. (LT_MODE_ARG): New variable. (strip_prefix, simplify_pkgconf_dir): New macros. (prefix, exec_prefix, includedir, bindir, libdir, datadir) (PKGCONF_EXEC_PREFIX, PKGCONF_INCLUDEDIR, PKGCONF_LIBDIR): New variables. (CFLAGS): Add -fPIC. (PKGCONF_DIR, LIBTOOL_LIBRARY, PKGCONF_FILE): New variables. (LIBTOOL, LIBTOOL_CC, LIBTOOL_LD): New variables. (LIBFLAGS): Delete variable. (CORE_LOBJECTS): New variable and target. ($(OBJ)/Core/%.c.o, $(OBJ)/SDL/%.c.o, $(OBJ)/XdgThumbnailer/%.c.o) ($(OBJ)/OpenDialog/%.c.o, $(OBJ)/%.c.o: %.c) ($(OBJ)/HexFiend/%.m.o: HexFiend/%.m) ($(OBJ)/%.m.o: %.m): Use $(LIBTOOL_CC). (lib): Express target via LIB_STATIC and LIB_SHARED; add $(PKGCONF_FILE). (install_headers, install_pkgconf_file): New macros. (install) [LIBRARY]: Conditionally add lib and pkgconf targets, as well as associated recipes. Adjust installation paths to use new variabes. ($(LIBDIR)/libsameboy.o, $(LIBDIR)/libsameboy.a): Delete targets. ($(LIBTOOL_LIBRARY), $(PKGCONF_FILE), pkgconf): New targets. (.PHONY): Register pkgconf. Add missing space between lib/lib-unsupported * README.md: Update doc. * sameboy.pc.in: New file.
Apteryks
force-pushed
the
build-and-install-shared-lib
branch
from
20ddb7f
to
d1c47a7
Compare
| ifneq (, $(shell command -v libtool 2> $(NULL))) | ||
| LIBTOOL := libtool | ||
| LIBTOOL_CC := $(LIBTOOL) --tag=CC --mode=compile $(CC) -c | ||
| LIBTOOL_LD := $(LIBTOOL) --tag=CC --mode=link $(CC) \ |
There was a problem hiding this comment.
And you really shouldn't be using libtool at all if you aren't use autotools, this is not going to be portable for slibtool.
There was a problem hiding this comment.
Seems slibtool (which I had no idea existed until now) is not fully compatible with libtool; am I not sure I understand the compatibility argument. Is it not a fault of slibtool to not being fully compatible with libtool? Where would this be an issue?
There was a problem hiding this comment.
Gentoo allows using slibtool where it works with most packages.
https://wiki.gentoo.org/wiki/Slibtool
Using libtool outside of autotools is always problematic and an extremely suboptimal way to use libtool. The GNU libtool script is one of the worst things ever written (Which is why slibtool exists).
There was a problem hiding this comment.
Using libtool outside of autotools is always problematic and an extremely suboptimal way to use libtool.
Could you expound on why you say it's "always problematic" to use libtool outside of Autotools? I'm curious of the reasons. I've found some peculiarities a bit challenging while authoring this diff, but I don't foresee problems with it. If Gentoo prefers slibtool, it seems that should work should work using LIBTOOL=slibtool as well, assuming the basic features of libtool I've made used are covered by this alternative implementation of it.
Regarding the quality of libtool itself, I don't particularly mind how pretty or ugly the innards of its implementation are; it's a battle-tested solution that simplified the problem at hand.
I don't mind revising this series more, but I'll need specific problems to address (I don't count "libtool is ugly" as one). Thank you for your continued input!
There was a problem hiding this comment.
GNU libtool is supposed to work by generating a ./libtool in the build tree during the ./configure process using LT_INIT from autoconf. The default slibtool symlink to use is rlibtool which depends on this existing so it can determine if it needs shared or static libraries and it will fail if this does not exist or if slibtoolize is not used instead.
Since this is not autotools there is ./configure, LT_INIT or libtoolize/slibtoolize and it will fail with flow errors.
https://wiki.gentoo.org/wiki/Slibtool#flow_error:_unexpected_condition_or_other
To be very blunt, this solution is entirely a non-starter.
There was a problem hiding this comment.
Could we s/libtool/slibtool/ and be done, if it fixes all these libtool shortcomings? Or is more complicated than than to switch to slibtool?
| Description: The SameBoy library | ||
| Version: @version@ | ||
| Cflags: -I${includedir}/sameboy | ||
| Libs: -L${libdir} -lsameboy |
There was a problem hiding this comment.
When linking libsameboy.a -lm appears to be needed
Libs.private: -lm
| -@rm $(OBJ)/lto_hack.o | ||
|
|
||
| $(LIBDIR)/libsameboy.a: $(LIBDIR)/libsameboy.o | ||
| $(LIBTOOL_LD) -rpath $(libdir) $^ -o $@ |
There was a problem hiding this comment.
rpaths are a general cause for problems and are discouraged wherever possible.
Fedora outright bans a lot of rpaths it considers "broken"
https://fedoraproject.org/wiki/Changes/Broken_RPATH_will_fail_rpmbuild#Definition_of_a_broken_RPATH
There was a problem hiding this comment.
Fwiw GNU libtool breaks without the -rpath (While Slibtool doesn't have this problem). Another reason to avoid using libtool here...
| includedir ?= $(prefix)/include | ||
| bindir ?= $(exec_prefix)/bin | ||
| libdir ?= $(exec_prefix)/lib | ||
| datadir ?= $(prefix)/share |
There was a problem hiding this comment.
this should probably be affected by or affect DATA_DIR
There was a problem hiding this comment.
Note that DATA_DIR is for that SameBoy specific data files like the bios while datadir is for package specific data files like the icons and desktop file. In autotools this is the difference between datadir and datarootdir.
There was a problem hiding this comment.
sure, I think the Makefile should have those two variables here as well.
Also, since a specific naming convention was already established with DATA_DIR and co., should these also follow the naming scheme?
There was a problem hiding this comment.
I think the Autotools convention is widely understood for packagers, so makes sense to follow. I was a bit confused that DATA_DIR meant something different than datadir for SameBoy at first.
There was a problem hiding this comment.
Using the autotools conventions you are using datadir as if it was datarootdir and DATA_DIR is what datadir would be.
There was a problem hiding this comment.
Oh! I had missed that. Then I guess I should rename the datadir I used to datarootdir and have a new datadir be an alias to DATA_DIR.
A new 'LIBRARY' variable also causes the libraries to be installed along the headers and a newly introduced pkg-config file.
(PKGCONF_DIR, LIBS, PKGCONF_FILE): New variables.
(lib): Express target via LIBS; add $(PKGCONF_FILE). (install) [LIBRARY]: Conditionally add lib and pkgconf targets, as well as associated recipes.
($(LIBDIR)/libsameboy.so, PKGCONF_FILE, pkgconf): New targets. (.PHONY): Register pkgconf.