recompile with -fPIC about pdfalto HOT 34 OPEN

Hi, I was having the same "relocation R_X86_64_32 against" errors. I'm on Debian stretch:

vagrant@stretch:~/git/pdfalto$ uname -a
Linux stretch 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux

I think all errors are from trying to link the libicuuc.a static library:

/usr/bin/ld: libs/icu/linux/64/libicuuc.a(uobject.ao): relocation R_X86_64_32 against symbol `__gxx_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(cmemory.ao): relocation R_X86_64_32 against `.rodata._ZL7zeroMem' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(unistr.ao): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(ustring.ao): relocation R_X86_64_32S against `.rodata._ZL12UNESCAPE_MAP' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(ustrtrns.ao): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
.. many more ..

I did use the install_deps.sh script, so I didn't know how to solve this with a pie executable.
Therefore I tried another solution, I added this to CMakeLists.txt:

   set(CMAKE_EXE_LINKER_FLAGS "-no-pie")

And this solved my problem:-)

from pdfalto.

you need to generate build file using the flag PIC as showed in the error.
So you need to run cmake this way :

cmake "-DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=true" .

from pdfalto.

On Arch Linux I have the same issue, to use the provided libs I used an ubuntu:16.04 container:

docker run -v $PWD:/mnt --rm -it ubuntu:16.04 bash -c "apt-get update -qq; apt-get install -qq cmake build-essential clang git; git clone --depth=50 --branch=master https://github.com/kermitt2/pdfalto.git --recursive; (cd pdfalto; cmake ./; make; cp pdfalto /mnt);" && sudo chown $(id -u):$(id -g) pdfalto

from pdfalto.

If you are encountering the same issue regarding the dependencies please refer to this section : https://github.com/kermitt2/pdfalto#dependencies
To fix this issue you'll need to run this script : https://github.com/kermitt2/pdfalto/blob/master/install_deps.sh

from pdfalto.

Nevermind.
sudo apt install pkg-config

from pdfalto.

Perfekt, thanks for being so patient with me. ;-)

from pdfalto.

Thank you for this feedback.
Could send the output of this command :

uname -i

from pdfalto.

from pdfalto.

$ uname -i
unknown
$ uname -a
Linux ... 4.19.13-1-lts #1 SMP Sun Dec 30 07:38:47 CET 2018 x86_64 GNU/Linux

from pdfalto.

Thanks for the information,
I can't reproduce this error in my environment, but I think you need to regenerate the libpng.a.
To do so you to go under libs/image/png/src and run :

cmake "-DCMAKE_POSITION_INDEPENDENT_CODE:BOOL=true" ./; make

This will generate a libpng.a file that you need to copy under libs/image/png/linux , since I understand you are using linux.

Please keep me informed.

from pdfalto.

from pdfalto.

Could you update your repository and re make it.

from pdfalto.

from pdfalto.

Ok, it seems that your linker is old.
Could you send the output of this

ld -v

from pdfalto.

What I suggest is you checkout the last updates and you compile the dependencies following the description here : https://github.com/kermitt2/pdfalto/blob/master/Dependencies_INSTALL.md

from pdfalto.

$ ld -v
GNU ld (GNU Binutils) 2.31.1

I think you'll agree that my linker is not 'old'.

Thanks for writing up the 'do it yourself' instructions even though the approach is hardly ideal to solve one's software's portability issues.

from pdfalto.

I've a bash script for installing the dependencies in one step , you can recompile all of the dependencies using this bash script https://github.com/kermitt2/pdfalto/blob/master/install_deps.sh

from pdfalto.

Hello,
Any updates about this issue, have you installed the dependencies using the shell script ?

from pdfalto.

hello @rytis-paskauskas
Could you give some updates about this issue

from pdfalto.

Hi,
sorry for the delay. To make it up for it, I ran two OSs: Arch and the latest Debian. Following a clean checkout.
Arch: failed (libpaper)
Debian: success

Here is the relevant output on Arch:
$ cmake ./
++ 64 bit architecture
-- Found FreeType (old-style includes): /opt/src/pdfalto/libs/freetype/linux/64/libfreetype.a
-- lcms2 not found
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/src/pdfalto

$ ./install_deps.sh
..... lots of warnings but no errors

$ make
[ 36%] Built target xpdf
[ 42%] Built target goo_objs
[ 43%] Built target goo
[ 48%] Built target fofi_objs
[ 48%] Built target fofi
[ 60%] Built target splash_objs
[ 61%] Built target splash
[ 62%] Linking CXX executable pdfalto
/usr/bin/ld: xpdf-4.00/build/xpdf/lib/libxpdf.a(GlobalParams.cc.o): in function GlobalParams::GlobalParams(char const*)': GlobalParams.cc:(.text+0xd81): undefined reference to paperinit'
/usr/bin/ld: GlobalParams.cc:(.text+0xd86): undefined reference to systempapername' /usr/bin/ld: GlobalParams.cc:(.text+0xda2): undefined reference to paperinfo'
/usr/bin/ld: GlobalParams.cc:(.text+0xdb2): undefined reference to paperpswidth' /usr/bin/ld: GlobalParams.cc:(.text+0xdc9): undefined reference to paperpsheight'
/usr/bin/ld: GlobalParams.cc:(.text+0xe0e): undefined reference to `paperdone'
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/pdfalto.dir/build.make:184: pdfalto] Error 1
make[1]: *** [CMakeFiles/Makefile2:76: CMakeFiles/pdfalto.dir/all] Error 2
make: *** [Makefile:130: all] Error 2

[rytis@pappa pdfalto] $ pacman -Ss libpaper
extra/libpaper 1.1.24-11 [installed]
Library for handling paper characteristics
$ pacman -Ql libpaper
libpaper /etc/
libpaper /etc/libpaper.d/
libpaper /etc/papersize
libpaper /usr/
libpaper /usr/bin/
libpaper /usr/bin/paperconf
libpaper /usr/bin/paperconfig
libpaper /usr/include/
libpaper /usr/include/paper.h
libpaper /usr/lib/
libpaper /usr/lib/libpaper.so
libpaper /usr/lib/libpaper.so.1
libpaper /usr/lib/libpaper.so.1.1.2
....

On Debian all went well.

from pdfalto.

Thanks for your feedback, I've corrected it, it should be ok by now.

from pdfalto.

Hi @Aazhar

I'm getting the same error actually. The script execution ends up with:

Copying libraries into their corresponding location.
cp: cannot stat 'install/libxml2-2.9.8/.libs/libxml2.a': No such file or directory
done.

from pdfalto.

During the process

Checking zlib
./configure: line 13059: syntax error near unexpected token `Z,zlib,'
./configure: line 13059: `        PKG_CHECK_MODULES(Z,zlib,'
make: *** No targets specified and no makefile found.  Stop.
libxml2 installation is finished.

from pdfalto.

set(CMAKE_EXE_LINKER_FLAGS "-no-pie") is not working for me i am getting the same error

/usr/bin/ld: /usr/local/lib/libbcrypt.a(wrapper.c.o): relocation R_X86_64_PC32 against symbol `_crypt_itoa64' can not be used when making a shared object; recompile with -fPIC

from pdfalto.

Hi, I was having the same "relocation R_X86_64_32 against" errors. I'm on Debian stretch:

vagrant@stretch:~/git/pdfalto$ uname -a
Linux stretch 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux

I think all errors are from trying to link the libicuuc.a static library:

/usr/bin/ld: libs/icu/linux/64/libicuuc.a(uobject.ao): relocation R_X86_64_32 against symbol `__gxx_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(cmemory.ao): relocation R_X86_64_32 against `.rodata._ZL7zeroMem' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(unistr.ao): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(ustring.ao): relocation R_X86_64_32S against `.rodata._ZL12UNESCAPE_MAP' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(ustrtrns.ao): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
.. many more ..

I did use the install_deps.sh script, so I didn't know how to solve this with a pie executable.
Therefore I tried another solution, I added this to CMakeLists.txt:

   set(CMAKE_EXE_LINKER_FLAGS "-no-pie")

And this solved my problem:-)

I was facing the same issue with other project

Hi, I was having the same "relocation R_X86_64_32 against" errors. I'm on Debian stretch:

vagrant@stretch:~/git/pdfalto$ uname -a
Linux stretch 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3 (2019-02-02) x86_64 GNU/Linux

I think all errors are from trying to link the libicuuc.a static library:

/usr/bin/ld: libs/icu/linux/64/libicuuc.a(uobject.ao): relocation R_X86_64_32 against symbol `__gxx_personality_v0' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(cmemory.ao): relocation R_X86_64_32 against `.rodata._ZL7zeroMem' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(unistr.ao): relocation R_X86_64_32 against `.bss' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(ustring.ao): relocation R_X86_64_32S against `.rodata._ZL12UNESCAPE_MAP' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: libs/icu/linux/64/libicuuc.a(ustrtrns.ao): relocation R_X86_64_32S against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
.. many more ..

I did use the install_deps.sh script, so I didn't know how to solve this with a pie executable.
Therefore I tried another solution, I added this to CMakeLists.txt:

   set(CMAKE_EXE_LINKER_FLAGS "-no-pie")

And this solved my problem:-)

Lifesaver. I was facing the same issue with another project.
set(CMAKE_EXE_LINKER_FLAGS "-no-pie") 💯 👍

from pdfalto.

Using a clean environment in docker I get exactly the same error. This is the sript I am executing

FROM debian:buster-slim as builder


RUN DEBIAN_FRONTEND=noninteractive \
    apt-get update && \
    apt-get install -y --no-install-recommends \
        ca-certificates wget sudo autoconf automake pkg-config cmake build-essential clang git && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

RUN git config --global url."https://github.com/".insteadOf [email protected]: && \
    git clone --depth=50 --branch=master https://github.com/kermitt2/pdfalto.git --recursive

WORKDIR pdfalto
RUN ./install_deps.sh
RUN cmake ./ && make

from pdfalto.

Aeh, you are downloading static libraries (usually illegal on many distros) and just linking against a libxml.a built
with whatever flags? This will totally not work and injects binary artifacts checked in into git of unknown source into the build!

Please link against the system libxml2 (which links against the correct system icu) or compile all sources from scratch as
subprojects (but why would you want to do that? If your version of xpdf is relying on old versions of standard libraries you should consider adapting the code).

This applies for all other libraries too:

set ( XML_LIBRARY ${XML_LIB_SUBDIR}/${OSSUFFIX}/${ARCHSUFFIX}/libxml2.a)
set ( PNG_LIBRARIES ${PNG_SUBDIR}/${OSSUFFIX}/${ARCHSUFFIX}/libpng.a)
set ( ZLIB_LIBRARY ${ZLIB_SUBDIR}/${OSSUFFIX}/${ARCHSUFFIX}/libzlib.a)
set ( FREETYPE_LIBRARY ${CMAKE_CURRENT_SOURCE_DIR}/libs/freetype/${OSSUFFIX}/${ARCHSUFFIX}/libfreetype.a)
set ( ICUUC_LIB ${CMAKE_CURRENT_SOURCE_DIR}/libs/icu/${OSSUFFIX}/${ARCHSUFFIX}/libicuuc.a)
set ( ICUDATA_LIB ${CMAKE_CURRENT_SOURCE_DIR}/libs/icu/${OSSUFFIX}/${ARCHSUFFIX}/libicudata.a)

from pdfalto.

Ok, I tried to patch and package it for Archlinux, so that it builds fine with system libraries. The result is here:
https://aur.archlinux.org/packages/pdfalto/

from pdfalto.

Thank you @andreasbaumann for your message

In this build, we are not trying to make a linux redistribution package that will be further linked by other library (it would be another build scenario). Here we are building a standalone executable to be portable and packaged in other tools (to avoid having the users of these tools to install pdfalto on their system and deal with library compatibility).

So our motivation here is not to link dynamically with the system libraries and not building something to be further linked with something else (afaik there is compiler and flag compatibility issues in this case).

you are downloading static libraries (usually illegal on many distros)

Could you elaborate why it would be illegal or point to some explanations? To my understanding, there is no problem to add to a GitHub repo some static libraries built from GPL compatible sources in a GPL project.

... injects binary artifacts checked in into git of unknown source into the build

The sources correspond to the script https://github.com/kermitt2/pdfalto/blob/master/install_deps.sh
Again the goal here is to facilitate a static build that can be embedded in other tools with minimal dependencies, not to create a linux package.

from pdfalto.

Well, illegal is a harsh term, sorry. :-)

Statically linked libraries have been built with all kind of flags affecting the ABI (PIC, PIE, stack smashing,
optimization flags, etc.), so it might not link on the target machine or expose strange behaviour.

Static libraries might pose a security risk, imagine a vulnerabilty gets fixed in libpng, but you still link statically against
an old version containing the vulerability.

The whole idea of doing packaging of software is to easy the installation for normal Linux users. But you leave the
last step of linking and building pdfalto to the end user, which results in the errors as seen above.

You end up in bitrot (for instance your C++ code depends on old deprecated APIs of libpng), which is not good
for the code quality on the long term.

from pdfalto.

@andreasbaumann So "bad practices" rather than illegal, I feel better with that :)

Thanks a lot for the Archlinux package, this is great contribution! Could you maybe suggest some notes about it to be added in the readme? Or I can just point to https://aur.archlinux.org/packages/pdfalto/ ?

I totally agree with you about packaging and that a statically link library is very bad distributable, sure. But this build was not intended for distributing a library, it's for building an executable that can work on a variety of outdated linux distro 64 bits and macos without any install for the end user (most would not do it). This is the scenario we needed pdfalto, which explains why we focused on it.

For doing this, I don't see how we can avoid freezing the dependencies as static libraries, this is pro and cons of static vs dynamic. Would you have suggestions how to improve building a portable executable ?

from pdfalto.

Yeah, this URL will do just fine. :-)

At least I would add the sources as 3rdParty git modules, so that you know where those binaries came from
(and in the worst case, they can be changed and rebuild). Or just have a README about how to rebuild it
from source.

from pdfalto.

Thank you @andreasbaumann

There is actually a README on building from sources -> https://github.com/kermitt2/pdfalto/blob/master/Dependencies_INSTALL.md (although libpng & zlib are from local source :/ )

Then the problem is that the availability of these sources as git module. For instance I had to create and update a git repo for xpdf myself to be able to add it as a git module - so it is only moving the maintenance problem elsewhere... but I can try to look again when I will update the pdfalto project in the next weeks/months.

from pdfalto.

... readme update for ArchLinux package adacaac

from pdfalto.