Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

tests: Remove .libs from linker paths. #24

Merged
merged 1 commit into from Apr 12, 2021
Merged

tests: Remove .libs from linker paths. #24

merged 1 commit into from Apr 12, 2021

Conversation

orbea
Copy link
Contributor

@orbea orbea commented Apr 8, 2021

When building libuninameslist with slibtool (https://dev.midipix.org/cross/slibtool) it fails.

rdlibtool --tag=CC --mode=link gcc -I.. -I.. -lm -g -O2 -o call-test0 call-test0.o ../.libs/libuninameslist.la

rdlibtool: lconf: {.name="libtool"}.
rdlibtool: fdcwd: {.fdcwd=AT_FDCWD, .realpath="/tmp/libuninameslist/tests"}.
rdlibtool: lconf: fstatat(AT_FDCWD,".",...) = 0 {.st_dev = 45, .st_ino = 168580}.
rdlibtool: lconf: openat(AT_FDCWD,"libtool",O_RDONLY,0) = -1 [ENOENT].
rdlibtool: lconf: openat(AT_FDCWD,"../",O_DIRECTORY,0) = 3.
rdlibtool: lconf: fstat(3,...) = 0 {.st_dev = 45, .st_ino = 168498}.
rdlibtool: lconf: openat(3,"libtool",O_RDONLY,0) = 4.
rdlibtool: lconf: found "/tmp/libuninameslist/libtool".
rdlibtool: error logged in slbt_get_deps_meta(), line 126: path not found: ../.libs/.libs/libuninameslist.a.slibtool.deps.
rdlibtool: < returned to > slbt_exec_link_create_executable(), line 1617.
rdlibtool: < returned to > slbt_exec_link(), line 2062.
make[1]: *** [Makefile:624: call-test0] Error 2
make[1]: Leaving directory '/tmp/libuninameslist/tests'
make: *** [Makefile:706: install-recursive] Error 1

This is because tests/Makefile.am adds .libs to the LDADD lines which is not correct. Ideally the build system should not use the .libs directories directly as they are for internal $(LIBTOOL) usage. GNU libtool does not fail because it is a lot more permissive.

Please see this downstream issue: https://bugs.gentoo.org/779670

@JoesCat
Copy link
Contributor

JoesCat commented Apr 9, 2021

Will look at this on the weekend. Thanks for your PR.
Would you mind taking a look at https://github.com/fontforge/libspiro - it has a similar make structure to libuninameslist

@orbea orbea mentioned this pull request Apr 9, 2021
Merged
@orbea
Copy link
Contributor Author

orbea commented Apr 9, 2021

I took a look at libspiro and found some issues, here is the PR fontforge/libspiro#31.

@JoesCat JoesCat merged commit 407b014 into fontforge:master Apr 12, 2021
@JoesCat
Copy link
Contributor

JoesCat commented Apr 12, 2021

I hadn't expected removing .libs to be the correct format.
Thanks for this fix - and also for libspiro as well.

orbea added a commit to orbea/libuninameslist that referenced this pull request May 14, 2022
@orbea
build: Link with .la files for internal deps
23db59a 
When building libuninameslist with --enable-frenchlib and slibtool the
build will fail when it can't find -luninameslist-fr.

However if libuninameslist is already installed to the system it will
compile successfully using the already installed version of
uninameslist-fr.so instead of the locally built new library.

This can be fixed by linking with the libtool archive (.la) instead as
should be done for internal dependencies while -l linker flags should be
only for external dependencies.

Additionally I removed the now redundant DEPENDENCIES and LIBADD line.

GNU libtool is less strict about user errors and will silently hide such
issues.

I missed this second issue until now when I fixed the previous issue in
PR fontforge#24.

Gentoo Bug: https://bugs.gentoo.org/779670
@orbea orbea mentioned this pull request May 14, 2022
Merged
orbea added a commit to orbea/libuninameslist that referenced this pull request May 14, 2022
@orbea
build: Link with .la files for internal deps
877fb14 
When building libuninameslist with --enable-frenchlib and slibtool the
build will fail when it can't find -luninameslist-fr.

However if libuninameslist is already installed to the system it will
compile successfully using the already installed version of
uninameslist-fr.so instead of the locally built new library.

This can be fixed by linking with the libtool archive (.la) instead as
should be done for internal dependencies while -l linker flags should be
only for external dependencies.

Additionally I removed the now redundant DEPENDENCIES and LIBADD line.

GNU libtool is less strict about user errors and will silently hide such
issues.

I missed this second issue until now when I fixed the previous issue in
PR fontforge#24.

Gentoo Bug: https://bugs.gentoo.org/779670
orbea added a commit to orbea/libuninameslist that referenced this pull request May 14, 2022
@orbea
build: Link with .la files for internal deps
fe3acc9 
When building libuninameslist with --enable-frenchlib and slibtool the
build will fail when it can't find -luninameslist-fr.

However if libuninameslist is already installed to the system it will
compile successfully using the already installed version of
uninameslist-fr.so instead of the locally built new library.

This can be fixed by linking with the libtool archive (.la) instead as
should be done for internal dependencies while -l linker flags should be
only for external dependencies.

Additionally I removed the now redundant DEPENDENCIES and LIBADD line.

GNU libtool is less strict about user errors and will silently hide such
issues.

I missed this second issue until now when I fixed the previous issue in
PR fontforge#24.

Gentoo Bug: https://bugs.gentoo.org/779670
orbea added a commit to orbea/libuninameslist that referenced this pull request May 14, 2022
@orbea
build: Link with .la files for internal deps
77f4eea 
When building libuninameslist with --enable-frenchlib and slibtool the
build will fail when it can't find -luninameslist-fr.

However if libuninameslist is already installed to the system it will
compile successfully using the already installed version of
uninameslist-fr.so instead of the locally built new library.

This can be fixed by linking with the libtool archive (.la) instead as
should be done for internal dependencies while -l linker flags should be
only for external dependencies.

Additionally I removed the now redundant DEPENDENCIES and LIBADD line.

GNU libtool is less strict about user errors and will silently hide such
issues.

I missed this second issue until now when I fixed the previous issue in
PR fontforge#24.

Gentoo Bugs:
	https://bugs.gentoo.org/779670
	https://bugs.gentoo.org/792474
@orbea orbea deleted the libs branch May 16, 2022 20:38
orbea added a commit to orbea/gentoo that referenced this pull request May 16, 2022
@orbea
media-libs/libuninameslist: Add 20211114
d06a4c2 
The patch fixes undefined references with slibtool when libuninameslist
is not already installed where it links with the installed package
rather than the newly compiled library.

The other bug was already fixed in upstream before the latest release.

Bug: https://bugs.gentoo.org/792474
Upstream-PR: fontforge/libuninameslist#27
Upstream-Commit: 77f4eea51b87c2e7a36cd3e1e64b424cdd5f7ad8

Bug: https://bugs.gentoo.org/779670
Upstream-PR: fontforge/libuninameslist#24
Upstream-Commit: 9192c8dfee8c9e437e841962fec78cba1093d0d6

Signed-off-by: orbea <orbea@riseup.net>
orbea added a commit to orbea/gentoo that referenced this pull request May 16, 2022
@orbea
media-libs/libuninameslist: Add 20211114
c67431a 
The patch fixes undefined references with slibtool when libuninameslist
is not already installed where it links with the installed package
rather than the newly compiled library.

The other bug was already fixed in upstream before the latest release.

Bug: https://bugs.gentoo.org/792474
Upstream-PR: fontforge/libuninameslist#27
Upstream-Commit: fontforge/libuninameslist@77f4eea

Bug: https://bugs.gentoo.org/779670
Upstream-PR: fontforge/libuninameslist#24
Upstream-Commit: fontforge/libuninameslist@9192c8d

Signed-off-by: orbea <orbea@riseup.net>
@orbea orbea mentioned this pull request May 16, 2022
Closed
orbea added a commit to orbea/gentoo that referenced this pull request May 16, 2022
@orbea
media-libs/libuninameslist: Add 20211114
b7c67d3 
The patch fixes undefined references with slibtool when libuninameslist
is not already installed where it links with the installed package
rather than the newly compiled library.

The other bug was already fixed in upstream before the latest release.

Bug: https://bugs.gentoo.org/792474
Upstream-PR: fontforge/libuninameslist#27
Upstream-Commit: fontforge/libuninameslist@77f4eea

Bug: https://bugs.gentoo.org/779670
Upstream-PR: fontforge/libuninameslist#24
Upstream-Commit: fontforge/libuninameslist@9192c8d

Signed-off-by: orbea <orbea@riseup.net>
gentoo-bot pushed a commit to gentoo/gentoo that referenced this pull request May 16, 2022
@orbea @thesamesam
media-libs/libuninameslist: Add 20211114
c73aabb 
The patch fixes undefined references with slibtool when libuninameslist
is not already installed where it links with the installed package
rather than the newly compiled library.

The other bug was already fixed in upstream before the latest release.

Bug: https://bugs.gentoo.org/792474
Upstream-PR: fontforge/libuninameslist#27
Upstream-Commit: fontforge/libuninameslist@77f4eea

Bug: https://bugs.gentoo.org/779670
Upstream-PR: fontforge/libuninameslist#24
Upstream-Commit: fontforge/libuninameslist@9192c8d

Signed-off-by: orbea <orbea@riseup.net>
Signed-off-by: Sam James <sam@gentoo.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@orbea @JoesCat