Salvador, I sent you this info in an email about 2 1/2 months ago, on Oct 7, 2022. I don't want to forget about it, so I will create an issue here. Here is what I said in the email. As a reminder, the topic is performing a build of a 32-bit binary on Linux 64-bit.

I worked on this issue some more. Thankfully, you just reversed my changes to common.imk, so all the other changes are still in there. Here are 3 separate options that enabled me to build an example after I built the 32-bit version of TVision under 64-bit Linux:

(1) Update common.imk to include RHIDE_LDFLAGS in RHIDE_COMPILE_LINK:

RHIDE_COMPILE_LINK=$(RHIDE_LD) $(RHIDE_LIBDIRS) $(LDFLAGS) $(RHIDE_LDFLAGS) $(C_EXTRA_FLAGS) -o $(OUTFILE)  $(OBJFILES) $(LIBRARIES) $(RHIDE_LIBS)
make -f tvedit.mkf

(2) make -f tvedit.mkf LDFLAGS=-m32 

(3) LDFLAGS=-m32 make -f tvedit.mkf

Of these options, I like (1) the best, because that makes things easiest for the developer (not the maintainer). Using this option addresses your concern about leaving LDFLAGS available for the developer to use.

As for your concern about RHIDE_LDFLAGS being used for dynamic linking, here's my thought about that. These build scripts are a mess. There's RHIDE_LIBS, RHIDE_OS_LIBS, CFLAGS, RHIDE_OS_CFLAGS, etc. To me, it looks like maintainers at different times weren't quite sure what each of these did, so they just added another one. During an actual build, there is only one final set of C flags, C++ flags and linker flags. So, I don't think we should keep introducing additional sets. Instead, let's use RHIDE_LDFLAGS so LDFLAGS remains available to the developer. For any particular build, the config process should determine the correct set of libs and headers required. If that particular build requires both the inclusion of the -m32 flag as well as a dynamic library, then we should just concatenate them together into RHIDE_LDFLAGS.

I respect that you've been maintaining TVision for a very long time, so defer to your judgment. Let me know how you'd like to proceed. Thanks.

[stephan@nuc:~/src/tvision/tvision/examples]$ g++ --version
g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
...

[stephan@nuc:~/src/tvision/tvision/examples]$ make
...
make[1]: Entering directory '/home/stephan/src/tvision/tvision/examples/i18n'
g++  -I../../include        -O2 -pipe -Wno-packed  -c test.cc -o test.o
test.cc: In function ‘int main()’:
test.cc:64:2: error: ‘strcpy’ was not declared in this scope
   64 |  strcpy(buffer, "LANG=es");
      |  ^~~~~~
test.cc:29:1: note: ‘strcpy’ is defined in header ‘<cstring>’; did you forget to ‘#include <cstring>’?
   28 | #include <tv.h>
  +++ |+#include <cstring>
   29 | 
make[1]: *** [test.umk:16: test.o] Error 1
make[1]: Leaving directory '/home/stephan/src/tvision/tvision/examples/i18n'
make: *** [Makefile:113: i18n/test.exe] Error 2

The patch very cleverly suggested by g++ is exactly correct and resolves the problem.

Hello,
I'm maintaing a package for Turbo Vision on Gentoo Linux, and I'm having a few issues with the build currently.

1. The call to ar when creating the libtvfintl.a static library is done via directly calling ar. The symbolic link of ar to the actual CHOST- prefixed ar might not exist, or might not be the binary we are looking for. It's use is discouraged in Gentoo Linux. Would it be possible, to add a search in the environment for AR before using plain ar, like you do in CheckGCC, CheckCFLAGS and others? I'd be glad to support you in this, but I don't have perl skills, but can only read and understand simple perl scripts, like the build scripts you are using, so my support could be somewhat limited. For some background on this with respect to Gentoo Linux, see https://wiki.gentoo.org/wiki/Project:Toolchain/use_native_symlinks
2. The dependency on gpm uses an automagic mechanism, i.e. if it's detected, support will be built in, if it's not detected, a warning is shown, stating that no mouse support will be available. This can cause issue when a user install's a package with gpm support and later uninstalls the package again, or decides he or she doesn't want gpm support for that package. Then gpm get's uninstalled. If, in the meantime, this user has built the tvision library, it will have gpm support built in, but the package manager doesn't know about this, because there's no flag indicating this. The same is true, if the user just doesn't want gpm support built into the library, there's currently no way to ignore gpm if it's installed on the system. After gpm get's uninstalled, the librhtv.so library is left in a broken state. Could you agree in adding a flag to the build system, to disable / enable support for gpm conditionally?
3. Just noticed the issue from point 2 is true for X11 and allegro as well.

Thanks for your interest.