Fix txzchk linking: add -lm for floorl/floor

[gaidardzhiev]

Problem
make clobber all fails due to undefined floorl/floor references:

/usr/sbin/ld: jparse/libjparse.a(json_parse.o): in function `json_process_floating':
json_parse.c:(.text+0x1e8): undefined reference to `floorl'
/usr/sbin/ld: json_parse.c:(.text+0x648): undefined reference to `floorl'
/usr/sbin/ld: json_parse.c:(.text+0x6ec): undefined reference to `floor'
collect2: error: ld returned 1 exit status
make: *** [Makefile:527: txzchk] Error 1

Fix
Add -lm to txzchk target (Makefile:527)

Results

• make clobber all succeeds
• ./txzchk -h works

Fixes ARMv8 32-bit Arch Linux build.

[xexyl]

Actually...this is in jparse, floor().

Thus this is the wrong repo.

Please do a pull request at https://github.com/xexyl/jparse and I'll be happy to merge it.

That being said it could be merged here prematurely. Still it has to be done in jparse.

If you can't (or don't want to) I can do it .. maybe later today. No problem either way.

Thanks!

[gaidardzhiev]

Sorry for submitting to the wrong repo and thanks for the quick clarification!

Please go ahead and apply the fix to jparse whenever you can, much appreciated. Happy to test the updated mkiocccentry once it's merged through the proper upstream channel.

Thanks!

[xexyl]

Sorry for submitting to the wrong repo and thanks for the quick clarification!

Please go ahead and apply the fix to jparse whenever you can, much appreciated. Happy to test the updated mkiocccentry once it's merged through the proper upstream channel.

Thanks!

Well it's okay if it's here because it has to be synced anyway and this way it would help out anyone with the issue.

It might or might not (that's up to Landon) not be merged until after IOCCC29 but it wouldn't hurt having it here either.

So by all means open this again with the caveat that it might not be merged (or it might be) until after this contest.

Thanks for the catch! Whichever way you go about it (reopening it or not) is fine though.

[xexyl]

Just pushed a change to jparse ... I hope GitHub does not have a problem with it (thinking of the -Wno- flag I had to add for macOS). If it did I will have to think of something else - and not now.

It might be better after all if the change I made is synced here now I think on it. Appreciate the report!

I would suggest for you to just keep your change as it is to help you out. Then for IOCCC30 it'll be merged.

Thanks again @gaidardzhiev!

[xexyl]

Suggestion: run from the top level directory in mkiocccentry the following command:

make jparse.recreate_clone jparse.update_from_clone

and then commit that. I forgot that certain things had to be done there.

Thanks!

[gaidardzhiev]

Thanks @xexyl for the suggestion!

Tried make jparse.recreate_clone jparse.update_from_clone but hit c_bool.h missing error in dyn_array/.

Per your advice, keeping original -lm fix as is to help ARM users now. Will look into the c_bool.h issue and sync jparse properly for IOCCC30.

Thanks for maintaining these awesome tools!

[xexyl]

Thanks @xexyl for the suggestion!

Tried make jparse.recreate_clone jparse.update_from_clone but hit c_bool.h missing error in dyn_array/.

Hmm ... Well that is from the dbg repo. That might be another bug but I am not certain of that.

What do you think @lcn2?

Per your advice, keeping original -lm fix as is to help ARM users now. Will look into the c_bool.h issue and sync jparse properly for IOCCC30.

ARM with linux anyway. This was missed because for whatever reason macOS links it in automatically - at least so I have seen - and Landon and I both develop primarily in macOS. Oddly linux even for x86_64 seems to not link it in yet it didn't trigger this issue in my tests.

Anyway thanks!

Thanks for maintaining these awesome tools!

Appreciate the kind words! It's been a lot of fun and an honour to work with Landon!

[xexyl]

Question for you @gaidardzhiev: does the change in jparse work when you sync it to your mkiocccentry directory? If not I'll look at (another day - after the contest possibly[0]) what you have done to see if it'll work.

[0] In which case if you need the change (as I guess) you should just go ahead and link it in the way you have done it. It shouldn't matter if you modify the Makefile to link in -lm. You'd have to get the new version for the next contest but that's another issue.

[gaidardzhiev]

@xexyl Thanks for the suggestion! The problem was me not installing all the deps (dbg/dyn_array/pr) system wide before so dyn_array failed with c_bool.h missing...

Now with all deps properly installed and fresh jparse sync, txzchk without -lm still fails floorl/floor linking on ARMv8 Linux 32bit so original error persists.

[0] In which case if you need the change (as I guess) you should just go ahead and link it in the way you have done it. It shouldn't matter if you modify the Makefile to link in -lm. You'd have to get the new version for the next contest but that's another issue

Perfect, will keep -lm as you suggested since I need the change and I will test on x86_64 Linux and x86 Linux these days to confirm platform scope.

Appreciate your help troubleshooting this!

[xexyl]

@xexyl Thanks for the suggestion! The problem was me not installing all the deps (dbg/dyn_array/pr) system wide before so dyn_array failed with c_bool.h missing...

Ah yes. That could cause problems.

Now with all deps properly installed and fresh jparse sync, txzchk without -lm still fails floorl/floor linking on ARMv8 Linux 32bit so original error persists.

Did you run the jparse sync commands? If so it's weird because I put in the Makefile there:

json_parse.o: json_parse.c
        ${CC} ${CFLAGS} -Wno-unused-command-line-argument json_parse.c -c -lm

So it should in theory work fine.

[0] In which case if you need the change (as I guess) you should just go ahead and link it in the way you have done it. It shouldn't matter if you modify the Makefile to link in -lm. You'd have to get the new version for the next contest but that's another issue

Perfect, will keep -lm as you suggested since I need the change and I will test on x86_64 Linux and x86 Linux these days to confirm platform scope.

It's curious. What linux are you using? It works in our linux systems. It's true that linux does not by default link in the math[s] library (and in fact some of the fixes I made to get older entries to work in linux was simply updating the LDFLAGS) and macOS does but it compiled fine in Rocky linux and earlier on CentOS. It also compiled fine in fedora although I can no longer test one.

Of course those are all RH based so that might be relevant ... and they were (and are) x86_64. My MacBook Pro is the M4 Max (though it worked with M1 Max too .. until macOS 26 bricked the bloody thing). Those are ARM chips of course (you said ARM).

Appreciate your help troubleshooting this!

Sure. It is weird if you did run the jparse commands but if you did we'll have to think of something else: maybe even doing what you did here as a workaround.

Let me know and thanks! Also good luck!

[xexyl]

Actually do me a favour when you can (not sure I can look at it in detail until after the contest though - between the fact we're running out of time and the Olympics I'm feeling the pressure and since you have a workaround for the time being I'm okay with delaying it). From the top level directory of the repo (the mkiocccentry repo) run:

./bug_report.sh

And then attach the log file here. Thanks!

[gaidardzhiev]

Yes, @xexyl, your fix appears correctly in jparse/Makefile and jparse/jparse binary links libm fine.
I suspect the issue is static library behavior. Even with your compile time -lm fix, the static lib still has undefined symbols that may need -lm at final link time.

grep -n "json_parse.c.*-c.*-lm" jparse/Makefile
541:    ${CC} ${CFLAGS} -Wno-unused-command-line-argument json_parse.c -c -lm

objdump -p jparse/jparse | grep NEEDED
NEEDED               libm.so.6
NEEDED               libc.so.6
NEEDED               ld-linux-armhf.so.3

ldd jparse/jparse
libm.so.6 => /usr/lib/libm.so.6 (0xeb060000)
libc.so.6 => /usr/lib/libc.so.6 (0xeaedb000)
/lib/ld-linux-armhf.so.3 => /usr/lib/ld-linux-armhf.so.3 (0x0f0
00000)

nm -u jparse/libjparse.a | grep floor
U floor
U floorl

make all
cc -std=gnu17 -O3 -pedantic -Wall -Wextra -Wno-char-subscripts -Wno-address -DINTERNAL_INCLUDE  txzchk.o soup/soup.a cpath/libcpath.a pr/libpr.a jparse/libjparse.a dyn_array/libdyn_array.a dbg/libdbg.a -o txzchk  /usr/sbin/ld: jparse/libjparse.a(json_parse.o): in function `json_process_floating':
json_parse.c:(.text+0x1e8): undefined reference to `floorl'
/usr/sbin/ld: json_parse.c:(.text+0x648): undefined reference to `floorl'
/usr/sbin/ld: json_parse.c:(.text+0x6ec): undefined reference to `floor'
collect2: error: ld returned 1 exit status
make: *** [Makefile:527: txzchk] Error 1

Platform: ARMv8 32bit Arch Linux in proot. Apologies for the obscure setup that perhaps nobody else uses... Will test on native Arch Linux x86_64 and x86 Void Linux later this week.

No urgency here! Happy to wait until after contest when you have breathing room.

Here's the bug report log:
bug-report.20260217.130904.txt

[xexyl]

I am admittedly a bit confused: you said it seems to fix it but there's still a linker error?

I guess I either read it wrong (entirely possible especially using the phone) or I misunderstood.

As far as the platform goes there's no reason to be apologetic about that. We want it as portable as possible. Also it's probably better than NetBSD which is in fact used by another veteran.

Thanks for providing the bug report log! Please do clarify the part that I was misunderstanding though.

Either way I am glad you have a workaround.

Important question: other tools also use that library so do any of them fail to link?

[gaidardzhiev]

@xexyl Thanks for the quick reply!

To clarify the confusion: your jparse fix only links -lm for the jparse binary itself (dynamic linking with libm.so.6, see ldd/objdump above), but doesn't resolve the static linking issue in txzchk:

make all
cc -std=gnu17 -O3 -pedantic -Wall -Wextra -Wno-char-subscripts -Wno-address -DINTERNAL_INCLUDE  txzchk.o soup/soup.a cpath/libcpath.a pr/libpr.a jparse/libjparse.a dyn_array/libdyn_array.a dbg/libdbg.a -o txzchk  /usr/sbin/ld: jparse/libjparse.a(json_parse.o): in function `json_process_floating':
json_parse.c:(.text+0x1e8): undefined reference to `floorl'
/usr/sbin/ld: json_parse.c:(.text+0x648): undefined reference to `floorl'
/usr/sbin/ld: json_parse.c:(.text+0x6ec): undefined reference to `floor'
collect2: error: ld returned 1 exit status
make: *** [Makefile:527: txzchk] Error 1

nm -u jparse/libjparse.a | grep floor
U floor
U floorl

Even with your compile time -lm on json_parse.o, the static libjparse.a still exports floor(l) as undefined symbols. So I think txzchk needs -lm at its final link step (Makefile:527).

Only my workaround of adding -lm in the mkiocccentry Makefile for the txzchk target works for me on ARMv8l 32bit Arch Linux. Your jparse -lm didn't resolve it.

No other tools fail because txzchk was the only target missing -lm, other tools (mkiocccentry, chkentry, chksubmit) already had -lm in their build rules. Quick test on native x86_64 Arch Linux and x86 Void Linux coming soon. Thanks again!

EDIT: Tested on x86_64 Arch Linux and x86 Void Linux:
nm -u jparse/libjparse.a | grep floor shows no unresolved symbols and the full mkiocccentry builds cleanly and works, without -lm on the txzchk target.

Bottom line: niche ARMv8l 32bit Arch Linux linking issue only, mkiocccentry builds and runs cleanly on x86_64 Arch Linux and x86 Void Linux without any changes.

[xexyl]

@xexyl Thanks for the quick reply!

To clarify the confusion: your jparse fix only links -lm for the jparse binary itself (dynamic linking with libm.so.6, see ldd/objdump above), but doesn't resolve the static linking issue in txzchk:

make all

cc -std=gnu17 -O3 -pedantic -Wall -Wextra -Wno-char-subscripts -Wno-address -DINTERNAL_INCLUDE  txzchk.o soup/soup.a cpath/libcpath.a pr/libpr.a jparse/libjparse.a dyn_array/libdyn_array.a dbg/libdbg.a -o txzchk  /usr/sbin/ld: jparse/libjparse.a(json_parse.o): in function `json_process_floating':

json_parse.c:(.text+0x1e8): undefined reference to `floorl'

/usr/sbin/ld: json_parse.c:(.text+0x648): undefined reference to `floorl'

/usr/sbin/ld: json_parse.c:(.text+0x6ec): undefined reference to `floor'

collect2: error: ld returned 1 exit status

make: *** [Makefile:527: txzchk] Error 1

nm -u jparse/libjparse.a | grep floor

U floor

U floorl

Even with your compile time -lm on json_parse.o, the static libjparse.a still exports floor(l) as undefined symbols. So I think txzchk needs -lm at its final link step (Makefile:527).

Only my workaround of adding -lm in the mkiocccentry Makefile for the txzchk target works for me on ARMv8l 32bit Arch Linux. Your jparse -lm didn't resolve it.

No other tools fail because txzchk was the only target missing -lm, other tools (mkiocccentry, chkentry, chksubmit) already had -lm in their build rules. Quick test on native x86_64 Arch Linux and x86 Void Linux coming soon. Thanks again!

EDIT: Tested on x86_64 Arch Linux and x86 Void Linux:

nm -u jparse/libjparse.a | grep floor shows no unresolved symbols and the full mkiocccentry builds cleanly and works, without -lm on the txzchk target.

Bottom line: niche ARMv8l 32bit Arch Linux linking issue only, mkiocccentry builds and runs cleanly on x86_64 Arch Linux and x86 Void Linux without any changes.

That's really bizarre: if other tools don't do it.

I am not at the computer now and only here briefly but it indeed is a simple solution.

The question is is it the right solution. That will have to be looked at later.

Thanks for clarifying.