Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

prelink: /usr/bin/........................................
i486-pc-linux-gnu-c++: Could not parse `        /usr/bin/........................................'
prelink: /usr/bin/........................................
i486-pc-linux-gnu-g++: Could not parse `        /usr/bin/........................................'
prelink: /usr/bin/........................................
i486-pc-linux-gnu-gcc: Could not parse `        /usr/bin/........................................'
prelink: /usr/bin/plaympeg: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/lib/svgalib/demos/linearspeed: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/bin/restorepalette: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/bin/gtv: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/i686-pc-linux-gnu/gcc-bin/3.3/g++ is no longer hardlink to /usr/i686-pc-linux-gnu/gcc-bin/3.3/c++
prelink: /usr/lib/svgalib/demos/bg_test: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/bin/glmovie: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/lib/svgalib/demos/joytest: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1
prelink: /usr/bin/emacs: COPY relocations don't point into .bss or .sbss section
prelink: /usr/lib/svgalib/demos/svidtune: Cannot prelink against non-PIC shared library /usr/lib/libvga.so.1


Reproducible: Always
Steps to Reproduce:
1. Start with fully sync'd Gentoo server machine
2. Type prelink -afmR as root
3. Swear in mild irritation, emerge svgalib.
4. Repeat.
Actual Results:  
I got a bunch of "cannot prelink..." messages related to libvga.so.1.


Expected Results:  
Prelinked cleanly!

The symlink to libvga.so.1.9.18 is intact.
The rest of the prelinking, so far as I can tell, worked as expected.

emerge info output:

System uname: 2.6.5-gentoo-r1 i686 Pentium III (Coppermine)
Gentoo Base System version 1.4.14
Autoconf: sys-devel/autoconf-2.59-r3
Automake: sys-devel/automake-1.8.3
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CFLAGS="-O3 -march=pentium3 -funroll-loops -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref
/usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O3 -march=pentium3 -funroll-loops -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache sandbox"
GENTOO_MIRRORS="[...deleted to save space...]"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X alsa apm arts avi berkdb crypt cups encode esd foomaticdb gdbm gif gnome
gpg gpm gtk gtk2 imap imlib jpeg libg++ libwww mad mbox mikmod motif mozilla
mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png ppds prelude
python qt quicktime readline sasl scanner sdl slang spell ssl svga tcpd tetex
truetype usb x86 xml2 xmms xv zlib"

I can confirm that one. The cause is in the ebuild file, which strips the
"-fPIC" flag for the gcc compiler. Libraries compiled without this flag cannot
be pre-linked...

see /usr/portage/media-libs/svgalib/svgalib-1.9.18-r1.ebuild
"...
src_compile() {

        filter-flags "-fPIC"
..."

I dunno what happens if you comment/remove this line, but maybe it is worth a
try.

Well, I've commented out the filter-flags "-fPIC" line from 
svgalib-1.9.18-r1.ebuild, and re-emerged it, and the good news is that so far
there are no ill effects.

The bad news is that prelink still complains about vgalib.so.

I've also tried unmerging and remerging svgalib, and no dice.

matthew svgalib-1.9.18-r1 # cd /usr/portage/media-libs/svgalib/               
matthew svgalib # grep fPIC *
ChangeLog:  Made all files compile with -fPIC, fixes prelink warnings.
svgalib-1.4.3-r4.ebuild:        filter-flags "-fPIC"
svgalib-1.9.17-r3.ebuild:       filter-flags "-fPIC"
svgalib-1.9.18-r1.ebuild:       # filter-flags "-fPIC"
svgalib-1.9.18.ebuild:  filter-flags "-fPIC"
matthew svgalib # 

I fixed this before but it seems to have broken again.
I will have a proper look at it by the latest this weekend.

If I recall correctly, the problem is that not all the object files which are compiled which go into the shared library libvga.so are compiled with the -fPIC CFLAG.

Look though your compile log and see if -fPIC is used to compile all the object code which goes into the library.

what about good old 1.9.19 ? :)

ok, here is a description of the cause:

In src/Makefile:

#lrmi must NOT be compiled as -fPIC
lrmi.o: lrmi.c
    $(CC) $(CFLAGS:-fPIC=) -c -o $@ $<

but lrmi.o is included in libvga.so, thus the error occours.

Now the reason for the above in the makefile:
In lrmi.c there is quite a bit of assembler.
Compiling with PIC takes up an extra register for realocations which may interfere with the hand written asm.

Anyone know enough about register usage on x86 to see if we can edit the makefile and fix the code? Failing that we could contact the author.

ps: it does compile with -fPIC as there is a #ifdef __PIC__ in the code for alternative asm, which if it was not there the compile would fail with:
lrmi.c:705: error: can't find a register in class `BREG' while reloading `asm'
( ie. register conflict )

I guess we could patch the makefile and test to see if it works.

I investigated what effect allowing lrmi.c to compile with -fPIC would make.

I could not trigger a codepath using libsvga which calls lrmi_vm86, none of the demos I tried called the function ( a simple printf line confirmed this )

But in the lrmi-0.6m directory is a nearly identical copy of lrmi.c. I edited the makefile here to compile with -fPIC. I also added a printf to show if the lrmi_vm86 function is called.

The program vbetest ran without errors, the stdout confirmed that the vm86 function was called. Same result as without -fPIC ( vga screen changes mode )

I guess this means it is safe to remove the Makefile section which make lrmi.c not compile with -fPIC.

svgalib-1.9.19 still filters the -fPIC flag, is there some work in progress?
any patches available? thx =)

cretin: could you fix it again plz?

ok, will patch the makefile to compile with -fPIC today ( a few hours time)

Done,
*svgalib-1.9.19-r1 (09 Sep 2004)

  09 Sep 2004; Stefan Jones <cretin@gentoo.org> +svgalib-1.9.19-r1.ebuild,
  +files/digest-svgalib-1.9.19-r1, +files/svgalib-1.9.19-pic.patch:
  Fix bug #51698, -fPIC not used to compile lrmi thus prelink complains

Please test, fixed it here. Will mark stable as soon at it is confirmed that it works for someone else also.

works fine here, thx

Closing bug then, marked stable.