Linking error for GraphicsMagick: relocation R_X86_64_32 against symbol

Johncc330 · 10-30-2023, 08:10 AM

Hi all.

Here's there sequence of actions (and reactions):

- Lacking time to recompile Inkscape at the time, I am using an AppImage of Inkscape 1.2.2. To my surprise I could not print, as the printer list was empty (I'd at least expected to have a print-to-file option, but even that was not there). All other programs print normally (Gimp, firefox, ...)

So I did some searches and found that several others had same experience around that time. There was a workaround, but it seemed complicated.

- I looked at slackbuilds and noticed the newest recipe was for Inkscape 1.3, so I downloaded it. Compiled and installed a couple of dependencies, and tried to do the same with Inkscape. It produced a linking problem with GraphicsMagick.

- Noticed that GM on slackbuilds was slightly newer, I decided to reinstall that one too. Paying attention to the warning, I first removepkg'd the previous version. Now I'm stuck at this strange compile error:

Code:

Running Mkbootstrap for Magick ()
chmod 644 "Magick.bs"
"/usr/bin/perl5.36.0" "/usr/share/perl5/ExtUtils/xsubpp"  -typemap '/usr/share/perl5/ExtUtils/typemap' -typemap '/usr/local/SBo/GraphicsMagick-1.3.40/PerlMagick/typemap'  Magick.xs > Magick.xsc
"/usr/bin/perl5.36.0" -MExtUtils::Command::MM -e 'cp_nonempty' -- Magick.bs blib/arch/auto/Graphics/Magick/Magick.bs 644
cp Magick.pm blib/lib/Graphics/Magick.pm
AutoSplitting blib/lib/Graphics/Magick.pm (blib/lib/auto/Graphics/Magick)
mv Magick.xsc Magick.c
gcc -c  -I../ -I.. -I/usr/include/freetype2 -I/usr/include/libxml2 -D_REENTRANT -D_GNU_SOURCE -fwrapv -fno-strict-aliasing -pipe -fstack-protector-strong -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -fopenmp -O2 -fPIC -Wall -O2 -fPIC   -DVERSION=\"1.3.40\" -DXS_VERSION=\"1.3.40\" -fPIC "-I/usr/lib64/perl5/CORE"  -D_LARGE_FILES=1 -DHAVE_CONFIG_H Magick.c
rm -f blib/arch/auto/Graphics/Magick/Magick.so
LD_RUN_PATH="/usr/lib64" gcc  -L/usr/lib64 -shared -O2 -fPIC -L/usr/local/lib -fstack-protector-strong -L/tmp/SBo/package-GraphicsMagick/usr/lib64 -lGraphicsMagick  Magick.o  -o blib/arch/auto/Graphics/Magick/Magick.so  \
   -L/usr/lib64 -lGraphicsMagick -lwebp -lwebpmux -lheif -lde265 -llcms2 -ltiff -lfreetype -ljasper -ljpeg -lpng16 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2 -lxml2 -lz -lzstd -lm -lpthread -lgomp   \
  
/usr/bin/ld: /usr/lib64/libGraphicsMagick.a(magick_libGraphicsMagick_la-analyze.o): relocation R_X86_64_32 against symbol `.gomp_critical_user_GM_GetImageDepthCallBack' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

Notice that the linking command already has the -fPIC option in its arguments (vs the error message 'recompile with -fPIC'). I also checked the Slackbuild recipe, and it has --enable-shared (which, I suppose, would add the -fPIC parameter).

Also, notice that the link command ends on a dangling '\'.

I'm at a loss on how to proceed:

- Why can't the appImage Inkscape 1.2.2 not see the print devices? Librecad, also an appImage, sees the printers.

- What causes the compilation problems with GraphicsMagick?

BrunoLafleur · 10-30-2023, 08:41 AM

For the compilation problem, is there a '/usr/lib64/libGraphicsMagick.a' which has stayed in the system ? Which don't get captured by the removepkg command ? which could have been put by another package or a direct install of some trying ?

The -fPIC has also to be there for the individuals .o objects file which are composing the static lib from which the dynamic lib is done.

I have compiled Inkscape in the past but not very recently. It was working. I didn't try the new version of GM but it should work.

Johncc330 · 10-30-2023, 10:12 AM

Quote:

Originally Posted by BrunoLafleur

For the compilation problem, is there a '/usr/lib64/libGraphicsMagick.a' which has stayed in the system ? Which don't get captured by the removepkg command ? which could have been put by another package or a direct install of some trying ?

The -fPIC has also to be there for the individuals .o objects file which are composing the static lib from which the dynamic lib is done.

Great! There were several .a files (from 2014!) laying around... I moved them out of sight, and compilation went ok. May I ask what gave that away? Or is that just years of accumulated experience?

I'll try and compile Inkscape now. Cheers!

BrunoLafleur · 10-30-2023, 10:30 AM

Quote:

Originally Posted by Johncc330

Great! There were several .a files (from 2014!) laying around... I moved them out of sight, and compilation went ok. May I ask what gave that away? Or is that just years of accumulated experience?

I'll try and compile Inkscape now. Cheers!

Well yes I do a lot of software development on Linux or Unix systems. Even if it is not my main job. I am an engineer searching in physicist sciences in a french organization. Often hard science need software tools and we have to know the family of systems and compilers in which we develop.

Johncc330 · 10-30-2023, 12:08 PM

Quote:

Well yes I do a lot of software development on Linux or Unix systems. Even if it is not my main job. I am an engineer searching in physicist sciences in a french organization. Often hard science need software tools and we have to know the family of systems and compilers in which we develop.

Though interested enough in hardware and software, I'm more of an applications guy... I like to combine electronics, microcontrollers and (mostly Python and C) programming.

Now, Inkscape compiled, installed and ran perfectly. And it recognized my printers too! I guess there are still some issues with the appImage system.

Again, much appreciated! A bientôt.