978b2a786834c7c7cd48542e802e857cd8d9302d brings link problem

[cathaysia]

when I build gr in 978b2a , it tell me:

FAILED: grm-plots
: && /usr/lib64/ccache/clang++ -g -rdynamic CMakeFiles/grm-plots.dir/grm-plots_autogen/mocs_compilation.cpp.o CMakeFiles/grm-plots.dir/lib/grm/grm-plots/grmplots.cxx.o CMakeFiles/grm-plots.dir/lib/grm/grm-plots/grmplots_mainwindow.cxx.o CMakeFiles/grm-plots.dir/lib/grm/grm-plots/grmplots_widget.cxx.o -o grm-plots  -Wl,-rpath,/home/tea/gr/build:::::::::::::::::::::  /usr/lib64/libQt5Widgets.so.5.15.8  libGRM.a  /usr/lib64/libQt5Gui.so.5.15.8  /usr/lib64/libQt5Core.so.5.15.8  libGKS.a  -lpthread  /usr/lib64/libz.so  -ldl  libGR3.so  libGR.so  -lm && :
/usr/bin/ld: libGR.so: undefined reference to `gks_ft_get_kerning'
/usr/bin/ld: libGR.so: undefined reference to `gks_ft_inq_bearing_x_direction'
/usr/bin/ld: libGR.so: undefined reference to `gks_ft_set_bearing_x_direction'
/usr/bin/ld: libGR.so: undefined reference to `gks_ft_get_metrics'
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.

978b2a is the first bad commit cause this problem.

[jheinen]

On which platform are you trying to build gr?

[cathaysia]

intel 11gen + fedora37

…

________________________________ From: Josef Heinen ***@***.***> Sent: Tuesday, March 7, 2023 10:13:57 PM To: sciapp/gr ***@***.***> Cc: DragonBillow ***@***.***>; Author ***@***.***> Subject: Re: [sciapp/gr] 978b2a7 brings link problem (Issue #174) On which platform are you trying to build gr? ― Reply to this email directly, view it on GitHub<#174 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKBJ6AIHI4EVXPLFL6LNTEDW247CLANCNFSM6AAAAAAVSGPUPE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[cathaysia]

intel 11gen+fedora37+gcc(with ccache)(or clang)

…

________________________________ From: 张 龙涛 ***@***.***> Sent: Tuesday, March 7, 2023 10:23:57 PM To: sciapp/gr ***@***.***>; sciapp/gr ***@***.***> Cc: Author ***@***.***> Subject: Re: [sciapp/gr] 978b2a7 brings link problem (Issue #174) intel 11gen + fedora37

________________________________ From: Josef Heinen ***@***.***> Sent: Tuesday, March 7, 2023 10:13:57 PM To: sciapp/gr ***@***.***> Cc: DragonBillow ***@***.***>; Author ***@***.***> Subject: Re: [sciapp/gr] 978b2a7 brings link problem (Issue #174) On which platform are you trying to build gr? ― Reply to this email directly, view it on GitHub<#174 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKBJ6AIHI4EVXPLFL6LNTEDW247CLANCNFSM6AAAAAAVSGPUPE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[IngoMeyer441]

I tried to reproduce the linker errors on a fresh Fedora 37, but couldn't so far. What I did:

sudo dnf groupinstall "Development Tools"
sudo dnf install \
    cmake \
    freetype-devel \
    gcc-c++ \
    libjpeg-turbo-devel \
    libpng-devel \
    qhull-devel \
    qt5-qtdeclarative-devel
git clone https://github.com/sciapp/gr.git
cd gr
cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build

How exactly did you try to build GR?
Did you try to compile without ccache?

[cathaysia]

thanks you for test。I'll test it tommor

…

________________________________ From: Ingo Meyer ***@***.***> Sent: Wednesday, March 8, 2023 5:34:35 PM To: sciapp/gr ***@***.***> Cc: DragonBillow ***@***.***>; Author ***@***.***> Subject: Re: [sciapp/gr] 978b2a7 brings link problem (Issue #174) I tried to reproduce the linker errors on a fresh Fedora 37, but couldn't so far. What I did: sudo dnf groupinstall "Development Tools" && \ sudo dnf install \ cmake \ freetype-devel \ gcc-c++ \ libjpeg-turbo-devel \ libpng-devel \ qhull-devel \ qt5-qtdeclarative-devel git clone https://github.com/sciapp/gr.git cd gr cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug How exactly did you try to build GR? Did you try to compile without ccache? ― Reply to this email directly, view it on GitHub<#174 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKBJ6ANM2LJOF3432DYMLR3W3BHCXANCNFSM6AAAAAAVSGPUPE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[cathaysia]

no. That is, is it convenient that I don't use ccache or there will be link problems.

[cathaysia]

I recorded a video to demonstrate my steps：

Peek.2023-03-09.14-40.mp4

I'm not quite sure why the result of our build is different. I'll try it later with a fedora container.
I've tried adding the relevant library in target_link_liraries in grm-plots , but that didn't work, it just caused more errors.

[danielkaiser]

Hi @cathaysia,

this would not explain why the issues start with the commit mentioned above, but I noticed the following in the video you recorded:

Please make sure to install the FreeType library and header so that it can be found by CMake (sudo dnf install freetype-devel should work).

[cathaysia]

OK, install freetype solved link problem. :)
Thank you very much.

[xiangluoming]

I have the same link problem. Seems if I don't have freetype, it failed to link.
But in the CMakelist.txt I see:

  if(FREETYPE_FOUND)
    target_link_libraries(${LIBRARY} ${GKS_LINK_MODE} Freetype::Freetype)
  else()
    target_compile_definitions(
      ${LIBRARY}
      ${GKS_LINK_MODE}
      NO_FT
    )
  endif()

Does this mean freetype is an optional dependence by design? Or on the contrary, freetype is just a required dependence?

[IngoMeyer441]

It should be possible to build GR without freetype, although it is highly recommended to use it for better font rendering. Getting a link error would indicate that freetype was found and used during compilation but that there are issues in the link stage. Could you provide some more details (used system and CMake log)? You can define

export VERBOSE=1

before running the build process to get a list of all executed commands.

[xiangluoming]

I build it on gentoo use the portage. Portage provides a USE mechanism to allow users to customize the compilation process. By turn off the 'freetype' USE flag in the gr package(which is by default), one can compile gr without freetype.
I've already issue a bug to gentoo. And there is my build.log.

[xiangluoming]

@IngoMeyer441 Can you reproduce it?
As the build log show, it seems if I compile it with NO_FT, then many gks_ft_* related function(for example gks_ft_get_kerning) in lib/gks/ft.c will not be defined. But when build libGR.so, it relies on these function. For example, /lib/gr/mathtex2.c uses function gks_ft_get_kerning. When build grplot, it link to libGR.so, which has some undefined reference, which end up causing this error.

[jheinen]

What would you expect how 3D text or LaTeX formulas should be rendered without outline fonts (provided by FreeType). What is the reason why you do not want to use the FT libraries? In which environment do you want to use GR?

[xiangluoming]

In fact I have freetype installed. But now that the gentoo gr package provide the freetype USE option, then it should work, at least it should install successfully. If it's impossible to compile without freetype, then the gentoo gr package should remove the freetype USE option and make it a mandatory dependency. I don't necessarily have to install gr in this case, just want to repair the gentoo package.

[IngoMeyer441]

@xiangluoming Yes, I can reproduce this. GR seems to expect Freetype functions even if NO_FT is defined. I will look into this next week...

[IngoMeyer441]

Should be fixed with ee77e31.

[xiangluoming]

It works. Thank you :)