Explain: Why does soap/bar.c require links to additional libraries when FUN is NOT defined?

[lcn2]

After doing a make all from the top level Makefile, cd into the soup/ directory and create following test C program, bar.c:

/*
 * bar - not defining FUN forces one to link additional libraries
 */

#include "foo.h"
#include "file_util.h"

int
main(void)
{
#if defined(FUN)
    vrergfB(-1, -1);
#endif
    return count_dirs(".");
}

Compile this code and run with:

cc -DFUN bar.c -c && cc bar.o ./soup.a ../dbg/libdbg.a -lm -o bar && ./bar

The above command compiles and links bar and the ./bar executable prints a fun message.

Now try to compile this same code WITHOUT FUN:

cc -UFUN bar.c -c && cc bar.o ./soup.a ../dbg/libdbg.a -lm -o bar

The above command will fail to link bar due to Undefined symbols.

Now compile this same code, again, WITHOUT FUN but this time with some additional libraries:

cc -UFUN bar.c -c && cc bar.o ./soup.a ../dbg/libdbg.a -lm \
    ../dyn_array/libdyn_array.a ../jparse/libjparse.a -lm -o bar && ./bar

This time, the code, WITHOUT FUN will compile and link. And of course, without the fun call, bar just exits as expected.

IMPORTANT POINT: Calling the vrergfB(-1, -1) function (i.e., some FUN) allows one to link bar with only a few libraries. By REMOVING THE CALL to vrergfB(-1, -1) function (i.e., without FUN), one is FORCED to link in additional libraries.

The task

Please explain WHY not defining FUN forces one to link additional libraries.

Is there some problem within this repo that causes this bizarre linking behavior? If so, what is needed to have a more library linkage dependency?

PLEASE NOTE: The bar.c is just a small test case. The goal of this task is to NOT to fix bar, nor is the goal move code into some external library as some form of "workaround". The goal is to explain this behavior, and once the behavior is understood, recommend any changes to this repo that might prevent this bizarre behavior from occurring.

This is a background priority task.

UPDATE 0

As things have moved around in this repo, use the code references in GH issuecomment-3416192644 instead of the code mentioned above.

[xexyl]

I am glad that it's a background priority. Shame it's revealing a certain function though.

Although it might be more fun that way.

I am not entirely sure that this should matter other than a curiosity - unless a problem shows up of course.

Maybe with this open I will look at it but not sure how much so I don't know because it isn't critical.

Leaving again. Feel free to assign for whatever that might be worth.

[xexyl]

... this is bonkers ... I have modified the file in various ways and tried different invocations of the compiler and linker .... it makes absolutely no sense at all.

I think one could go mad trying to sort this out. I do know it happens in both linux and macOS, at least those I tested.

I guess one thing would be to try and figure out if other functions would also cause this. But that will not explain why it only happens when a macro is defined or undefined. It certainly is not because it exits. We already discussed that. We both knew this but it's good to get it out. If one changes the function to just something that does not exit it still has the problem anyway. For instance:

/*
 * bar - not defining FUN forces one to link additional libraries
 */

#include "foo.h"
#include <stdio.h>
#include "file_util.h"

int
main(void)
{
#if defined(FUN)
    printf("test\n");
//    vrergfB(-1, -1);
#endif
    return count_dirs(".");
}

It fails to link as we'd expect. Even though we should not have this problem in only some cases. It should be required in all cases though since count_dirs() relies on them. That's the strangest thing for me.

What I wonder is what other functions would trigger this. But you'd think that including libsoup.a would require the others always since libsoup.a needs those libraries not sometimes but always - at least to link properly - and not sometimes.

[lcn2]

We find the fd_is_ready() function in jparse/util.c to be particularly problematic in link.

The fd_is_ready() function helps to support stdio operations, once someone uses fileno(3) to obtain the file descriptor.

The flush_tty() helps to support stdio operations as it works on stdin, stdout and stderr.

For these reasons we have moved fd_is_ready() from jparse/util.c to pr/pr.c. and move flush_tty() from soup/util.c to pr/pr.c.

To support this, we have updated libpr via commit 4db771fc9954b507cd3f0f4e8ee2a027587d5197. We have contributed pr 44 to the jparse repo, and commit 487a1e2 in this repo.

UPDATE 0

The above does NOT resolve this puzzle, it only helps with a particular instance we encounter during development. As the functions in question were within the scope of a "stdio helper function", we made the above moves.

[lcn2]

Quick update - still not a priority

Just a quick update to the "reference" code for this issue: As things have moved around in this repo, use the following soap/bar.c: code instead of what is mentioned in the first comment:

/*
 * bar - not defining FUN forces one to link additional libraries
 *
 * Place this var.c source under `soup/`.  Compile this code and run with:
 *
 *  cc -DFUN bar.c -c && cc bar.o ./soup.a ../dbg/libdbg.a -lm -o bar && ./bar
 *
 * All is well, as you can enjoy the fun message.
 *
 * Now try to compile this same code WITHOUT FUN:
 *
 *  cc -UFUN bar.c -c && cc bar.o ./soup.a ../dbg/libdbg.a -lm -o bar
 *
 * That will fail to link.
 *
 * WITHOUT FUN, this code fails to link unless you do:
 *
 *  cc -UFUN bar.c -c && cc bar.o ./soup.a ../cpath/libcpath.a ../pr/libpr.a ../dbg/libdbg.a \
 *      ../dyn_array/libdyn_array.a ../jparse/libjparse.a -lm -o bar && ./bar
 *
 * WHY???
 */

#include "foo.h"
#include "file_util.h"

int
main(void)
{
#if defined(FUN)
    vrergfB(-1, -1);
#endif
    return exists(".");
}

[xexyl]

Just saw your comment from earlier and this one too. Thanks.

I do not know that I have the faculties right now to even consider this puzzle. It IS curious but I'm not sure if it's the most useful thing to try and figure out, at least not immediately. In any case I can't do it right now.

The question I have for you is how important is this really? My guess is this is not necessary for IOCCC29 and in fact trying to solve it before IOCCC29 would be going against getting it ready to run by December. Is that right?

[xexyl]

... ah ... just saw the not a priority part. You can forget the question then. Still wanted to acknowledge the comments.

[xexyl]

Well one thing is clear: it has nothing to do with the no return attribute. You'd not expect the compiler to know that anyway (as it's only called depending on a definition) but I just confirmed it anyway.

It is so bizarre. Not focusing on this of course ... just saw the file in my directory and remembered I had to correct it. Had a fun comment update also in a commit.

That's all for the day I'm sure.

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.