• Compiling htick

    From Wilfred van Velzen@2:280/464 to Developers on Thursday, December 03, 2020 18:27:36
    Hi All,

    FYI: I had to make 1 change to the CMakeLists.txt file for huskylib to be able to compile htick on my new system:

    =========================================================================== diff --git a/CMakeLists.txt b/CMakeLists.txt
    index df5c00e..b0fbe1e 100644
    -+- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -36,6 +36,7 @@ if (MSVC)
    ADD_DEFINITIONS(-DWIN32 -D_WINDOWS -D_CONSOLE -D_CRT_SECURE_NO_WARNINGS)
    else ()
    ADD_DEFINITIONS(-Wall -DUNIX)
    + ADD_DEFINITIONS(-fPIC)
    endif (MSVC)

    message("-------------------------") ===========================================================================

    Otherwise I get linker errors when compiling smapi (and probably the other modules too):

    ===========================================================================
    ...
    [ 87%] Building C object CMakeFiles/smapi.dir/src/sq_write.c.o
    [ 93%] Building C object CMakeFiles/smapi.dir/src/structrw.c.o
    [100%] Linking C shared library libsmapi.so /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libhusky.a(cvtdate.c.o): relocation R_X86_64_32S against symbol `months_ab' can not be used when making a shared object; recompile with -fPIC
    /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libhusky.a(memory.c.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libhusky.a(strext.c.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libhusky.a(log.c.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libhusky.a(xstr.c.o): relocation R_X86_64_32 against `.rodata'
    can not be used when making a shared object; recompile with -fPIC /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /usr/local/lib64/libhusky.a(ftnaddr.c.o): warning: relocation against `free@@GLIBC_2.2.5' in read-only section `.text'
    collect2: error: ld returned 1 exit status
    gmake[2]: *** [CMakeFiles/smapi.dir/build.make:312: libsmapi.so.2.5.0] Error 1 gmake[1]: *** [CMakeFiles/Makefile2:93: CMakeFiles/smapi.dir/all] Error 2 gmake: *** [Makefile:169: all] Error 2 ===========================================================================


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Saturday, December 05, 2020 21:47:38
    Hello Wilfred,

    Thursday December 03 2020, Wilfred van Velzen wrote to Developers:

    FYI: I had to make 1 change to the CMakeLists.txt file for huskylib to
    be able to compile htick on my new system:

    ====================================================================== ===== diff --git a/CMakeLists.txt b/CMakeLists.txt index
    df5c00e..b0fbe1e 100644 -+- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -36,6 +36,7 @@ if (MSVC)
    ADD_DEFINITIONS(-DWIN32 -D_WINDOWS -D_CONSOLE -D_CRT_SECURE_NO_WARNINGS) else ()
    ADD_DEFINITIONS(-Wall -DUNIX)
    + ADD_DEFINITIONS(-fPIC)
    endif (MSVC)

    message("-------------------------") ====================================================================== =====

    Otherwise I get linker errors when compiling smapi (and probably the
    other modules too):

    ====================================================================== =====
    ...
    [ 87%] Building C object CMakeFiles/smapi.dir/src/sq_write.c.o
    [ 93%] Building C object CMakeFiles/smapi.dir/src/structrw.c.o
    [100%] Linking C shared library libsmapi.so
    ^^^^^^^^^^^
    /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/l
    d: /usr/local/lib64/libhusky.a(cvtdate.c.o): relocation R_X86_64_32S
    ^^^^^^^^^^
    I forwarded your message to Alexander Skovpen who wrote CMakeLists.txt for htick. He answered that
    you tried to link shared (i.e. dynamic) library libsmapi.so to the static library libhusky.a. This was incorrect. Either you build everything statically or you build everything dynamically.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Wilfred van Velzen@2:280/464 to Michael Dukelsky on Saturday, December 05, 2020 21:53:11
    Hi Michael,

    On 2020-12-05 21:47:38, you wrote to me:

    FYI: I had to make 1 change to the CMakeLists.txt file for huskylib
    to
    be able to compile htick on my new system:

    ======================================================================
    ===== diff --git a/CMakeLists.txt b/CMakeLists.txt index
    df5c00e..b0fbe1e 100644 -+- a/CMakeLists.txt
    +++ b/CMakeLists.txt
    @@ -36,6 +36,7 @@ if (MSVC)
    ADD_DEFINITIONS(-DWIN32 -D_WINDOWS -D_CONSOLE
    -D_CRT_SECURE_NO_WARNINGS) else ()
    ADD_DEFINITIONS(-Wall -DUNIX)
    + ADD_DEFINITIONS(-fPIC)
    endif (MSVC)

    message("-------------------------")
    ======================================================================
    =====

    Otherwise I get linker errors when compiling smapi (and probably the
    other modules too):

    ======================================================================
    =====
    ...
    [ 87%] Building C object CMakeFiles/smapi.dir/src/sq_write.c.o
    [ 93%] Building C object CMakeFiles/smapi.dir/src/structrw.c.o
    [100%] Linking C shared library libsmapi.so
    ^^^^^^^^^^^
    /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/l
    d: /usr/local/lib64/libhusky.a(cvtdate.c.o): relocation R_X86_64_32S
    ^^^^^^^^^^
    I forwarded your message to Alexander Skovpen who wrote CMakeLists.txt for htick. He answered that you tried to link shared (i.e. dynamic) library libsmapi.so to the static library libhusky.a. This was incorrect. Either you build everything statically or you build everything dynamically.

    Well then maybe the INSTALL.md for huskylib should be changed. It now states:

    $ cmake -H. -Bbuild -DBUILD_SHARED_LIBS=OFF

    See: https://github.com/huskyproject/huskylib/blob/master/INSTALL.md

    The INSTALL.ms for the other modules don't include the "-DBUILD_SHARED_LIBS=OFF"


    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Kai Richter@2:240/77 to Wilfred van Velzen on Sunday, December 06, 2020 00:27:32
    Hello Wilfred!

    05 Dec 20, Wilfred van Velzen wrote to Michael Dukelsky:

    Well then maybe the INSTALL.md for huskylib should be changed. It now states:

    $ cmake -H. -Bbuild -DBUILD_SHARED_LIBS=OFF

    Since i had trouble to move an exsiting config to an upgraded system i prefer the static method for my fidonet software.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)
  • From Wilfred van Velzen@2:280/464 to Kai Richter on Sunday, December 06, 2020 12:15:08
    Hi Kai,

    On 2020-12-06 00:27:32, you wrote to me:

    Well then maybe the INSTALL.md for huskylib should be changed. It now
    states:

    $ cmake -H. -Bbuild -DBUILD_SHARED_LIBS=OFF

    Since i had trouble to move an exsiting config to an upgraded system i prefer the static method for my fidonet software.

    The INSTALL.md's for the different modules shouldn't conflict with each other! When you follow the instructions in all of them you should be able to build all
    of them without conflicts...

    Bye, Wilfred.

    --- FMail-lnx64 2.1.0.18-B20170815
    * Origin: FMail development HQ (2:280/464)
  • From Michael Dukelsky@2:5020/1042 to Wilfred van Velzen on Sunday, December 06, 2020 20:08:22
    Hello Wilfred,

    Saturday December 05 2020, Wilfred van Velzen wrote to Michael Dukelsky:

    Well then maybe the INSTALL.md for huskylib should be changed. It now states:

    $ cmake -H. -Bbuild -DBUILD_SHARED_LIBS=OFF

    See: https://github.com/huskyproject/huskylib/blob/master/INSTALL.md

    The INSTALL.ms for the other modules don't include the "-DBUILD_SHARED_LIBS=OFF"

    Thanks for your comment. I have corrected INSTALL.md in all projects where it was needed.

    Michael

    ... node (at) f1042 (dot) ru
    --- GoldED+/LNX 1.1.5-b20170303
    * Origin: Moscow, Russia (2:5020/1042)
  • From Kai Richter@2:240/77 to Wilfred van Velzen on Monday, December 07, 2020 19:27:00
    Hello Wilfred!

    06 Dec 20, Wilfred van Velzen wrote to Kai Richter:

    It now states:
    $ cmake -H. -Bbuild -DBUILD_SHARED_LIBS=OFF

    Since i had trouble to move an exsiting config to an upgraded
    system i prefer the static method for my fidonet software.

    The INSTALL.md's for the different modules shouldn't conflict with
    each other!

    Sorry, i do agree absolutly. My intention was a pointer into a failsafe default
    configuration. ;-)

    For todays fidonet software i would like to see a "will continue operartion in the future regardless what changes to the system libs will come". This would give users the chance to operate the software even if there is noboby there who
    could do modifications for a successful re-compilation.
    But back to your topic.

    I'm irritated about that compilation command. Within my outdated source copy there is a huskymak.cfg as a central point for compilation configuration. All husky modules Makefiles here do refer with include ../huskymak.cfg or other paths. That would include $DYNLIBS that will trigger the -static compilation if
    set in huskymak.cfg.

    This maybe outdated because of 2012:
    [...]
    DYNLIBS=1
    EXENAMEFLAG=-o
    WARNFLAGS=-Wall
    ARCH=-m32
    OPTCFLAGS=-c -s -O3 -fomit-frame-pointer -fstrength-reduce -fPIC $(ARCH)
    ifeq ($(DYNLIBS), 0)
    ifeq ($(OSTYPE), UNIX)
    WARNFLAGS+= -static
    OPTCFLAGS+= -static
    endif
    endif
    [...]

    And the only cmake reference in my source is of bscmake.exe.

    Regards

    Kai

    --- GoldED+/LNX 1.1.4.7
    * Origin: Monobox (2:240/77)