[zyv]

Proposed changes

The low-level LIBS variable of autotools does not provide dependency tracking for sources and also does not resolve interdependencies between libraries.

Replace it with high-level LDADD to make sure that tests get re-linked when underlying source files change, and also automatically consider dependent libraries.

• Resolves: make check doesn't pick up changes to the code #4803

[egmontkob]

Verified again that it fixes my problem, thanks! :)

Can't comment on the implementation details.

[zyv]

The annoying Ubuntu issue must be because of the great Debian ideas around --as-needed and/or their custom libtool patches :( I'd appreciate any help if anyone has an easy/clean answer to that.

[egmontkob]

Do you mean this CI failure?

  CCLD     mc_build_filename
/usr/bin/ld: mc_build_filename.o: undefined reference to symbol 'g_free'
/usr/bin/ld: /lib/x86_64-linux-gnu/libglib-2.0.so.0: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:836: mc_build_filename] Error 1

Unfortunately I have no idea.

I'm on Ubuntu 25.10, from a clean repo with your patch ./autogen.sh && ./configure && make && make check worked fine for me.

[zyv]

I'm on Ubuntu 25.10, from a clean repo with your patch ./autogen.sh && ./configure && make && make check worked fine for me.

Yes, exactly. Our CI runs on Ubuntu 24.04 LTS. Maybe they finally decided to stop the nonsense by the time 25.10 got released? If yes, too bad it didn't make it into the LTS. :(

[egmontkob]

Works for me on my 24.04 computer, too.

It must be something different, some compile flags or LDFLAGS or some other difference in the enrivonment.

[zyv]

Works for me on my 24.04 computer, too.

It must be something different, some compile flags or LDFLAGS or some other difference in the enrivonment.

Try --enable-mclib ^__^

[egmontkob]

Haha, sorry.

Broken on 25.10 too.

[mc-worker]

How co cancel my approval?

I have an error with --enable-mclib=yes:

CCLD     mc_build_filename
ld: mc_build_filename.o: undefined reference to symbol 'g_free'
ld: /lib64/libglib-2.0.so.0: error adding symbols: DSO missing from command line

[mc-worker]

-if ENABLE_MCLIB
-LIBS += $(GLIB_LIBS) \
-	@E2P_LIBS@
-endif
+LDADD = \
+	$(top_builddir)/lib/libmc.la \
+	@CHECK_LIBS@

Each of test executables must be linked with all required libraries, but $(GLIB_LIBS) and @E2P_LIBS@ are removed now.

[ossilator]

the linking error probably stems from unintentional reliance on a transitive dependency, that is, some module uses glib, but fails to explicitly link it.

note that libs/modules should use LIBADD, not LDADD, iiuc.

[zyv]

How co cancel my approval?

I don't think that you can remove your approval with GitHub, but what you can do instead is to leave a new review requesting changes. This effectively cancels your previous approval.

[zyv]

-if ENABLE_MCLIB
-LIBS += $(GLIB_LIBS) \
-	@E2P_LIBS@
-endif
+LDADD = \
+	$(top_builddir)/lib/libmc.la \
+	@CHECK_LIBS@

Each of test executables must be linked with all required libraries, but $(GLIB_LIBS) and @E2P_LIBS@ are removed now.

Yes, me removing these statements is correct and intentional. The question is how do you organize the linking of your executables?

---

When you link your executable with an internal library that is part of your project like libinternal.la, then libtool automatically inspects the dependencies of this library and will also link all required libraries by libinternal.la to your executables.

So either, you can define a variable that contains all the libraries that your executable needs, like MCLIBS and then specify mc_LDADD = $(MCLIBS) for all of your executables like mc.

Or you can organize your code in internal libraries and specify the dependencies for these libraries, like libinternal.la and libmc.la (and possibly also add additional dependencies to the executable).

---

Our build system uses this second way: mc_LDADD only contains the references to the internal libraries (confusingly, libinternal.la and libmc.la if ENABLE_MCLIB is false, but only libinternal.la, which is then made to depend upon libmc.la if it's true), and libtool would resolve the sum of all dependencies needed.

The tests, for whatever reason, used low-level LIBS instead of LDADD, which is more like adding a or so files to the list of libraries directly, bypassing the source dependency tracking and library dependency tracking magic.

The consequence was that you had to specify transitive dependencies yourself in addition to the libraries themselves, and also that if source files were changing the tests were not correctly rebuilt. I didn't investigate who introduced that code and why, but clearly, it's a misguided idea, to stay civil.

---

Now I changed it to depend on the libraries in the correct way, fixing the source dependency tracking and automatic transitive dependency lookup. However, it has the consequence of breaking the build if --enable-mclib is set. Why and what does this do? This flag causes the build system to produce an so file out of mclib instead of leaving it as an internal library.

The reason why this is a questionable idea in the first place is explained at length in #4803. Of course, in addition to that, we are obviously doing it wrong because mc somehow links correctly, but the tests that depend on it are missing transitive dependencies.

I didn't check exactly why it happens, but either we are generally doing it wrong or it fails due to the interaction with Debian libtool patches specifically.

---

In any case, I think I've had enough of this nonsense. It's time to remove the generation of the useless shared library. I will create a separate ticket for that.

[zyv]

the linking error probably stems from unintentional reliance on a transitive dependency, that is, some module uses glib, but fails to explicitly link it.

note that libs/modules should use LIBADD, not LDADD, iiuc.

I'm not quite sure what you mean here. The tests are binaries, not libraries, so I'm using LDADD.

[ossilator]

but it could be relevant for the missing transitive dep. just a random idea.

[zyv]

I have rebased this one on top of #5192. This should fix the build failure with --enable-mclib, because the option is removed :)

[zyv]

/rebase