i have no idea how the hardened toolchain is set up on LFS.  -nonow might not be
a valid linker option, try -z nonow.

if you can come up with a reliable way of detecting a hardened compiler i'm all
ears.

This script adds options to alter the basic gcc options to have stack smashing
protection. Also default is -fPIC -fPIE or suchlike, for position independent code.

cat > hardened-specs.sh << "EOF"
#!/bin/sh
perl -pi -e 's@\*cc1:\n@$_%(cc1_ssp) @;' \
    $(gcc --print-file specs) &&
perl -pi -e 's@\*cc1plus:\n@$_%(cc1_ssp) @;' \
    $(gcc --print-file specs) &&
echo '*cc1_ssp: 
%{!fno-stack-protector*: -fstack-protector-all}
'    >> $(gcc --print-file specs)
perl -pi -e 's@\*cc1:\n@$_%(cc1_pie) @;' \
    $(gcc --print-file specs) &&
perl -pi -e 's@\*cc1plus:\n@$_%(cc1_pie) @;' \
    $(gcc --print-file specs) &&
perl -pi -e 's@%{pie:-pie}@%(link_pie)@;' \
    $(gcc --print-file specs) &&
perl -pi -e 's@pie:@!no-pie|pie:@g;' $(gcc --print-file specs) &&
perl -pi -e 's@\*cpp:\n@$_%(cpp_pie) @;' $(gcc --print-file specs) &&
echo '*cpp_pie: 
%{!static:%{!no-pie:%{!pie: -D__PIC__ -DPIC}}}
' >> $(gcc --print-file specs) &&
echo '*cc1_pie: 
%{!static:%{!no-pie:%{!pie: -fPIC}}}
' >> $(gcc --print-file specs) &&
echo '*link_pie: 
%{pie:-pie}%{!no-pie:%{!static:%{!Bstatic:%{!i:%{!r: %{!nonow: -z now} \
%{!norelro: -z relro} %{!shared:%{!Bshareable:%{!pie: -pie}}}}}}}}
' >> $(gcc --print-file specs)
EOF
NB. The second last line is folded. Remove my baclslash & Unfold it in your copy.

This C program tests the stack smashing code
cat > test.c << "EOF"
#include <stdio.h>
#include <unistd.h>
extern long __guard[];
int overflow(char *test) {
  char buffer[7];
  sprintf(buffer, "12345678901234567890123456789012345678901234567890");
  return(1234);
}
int main(int argc, char **argv) {
  printf("__guard\t=\t0x%08x;\n", __guard[0]);
  overflow("test");
  printf("This line should never get printed.\n");
}
EOF
It segfaults on a standard system, but the guard catches it on ssp systems.
I will consult with the hardening heads in LFS and pass on anything I get.

/Bangs head

We're TELLING you it's a hardened system - you don't have to check for it
From Host.def

#define HardenedGccSpecs  YES
#define ProPoliceSupport  YES

The word from the gurus at LFS is

To check for a pic compiler:
#if defined(__PIC__) || defined(__pic__)

To check for ssp:
#if defined( __SSP__)

To check for -z now they could grep from readelf. I'm not sure of a better 
way. (robert at linuxfromscratch dot org)

Created attachment 4393 [details]
Compiler specs files - a workaround

I worked around the problem as follows, and enclose 2 gcc specs files.
LD is defined as 'gcc -m32 -nostdlib' in X, and Line 135 shows an important
change
where the %{!nonow -z now} spec was removed. Xorg compiled through with
specs.old, which doesn't have this option. Furthermore, X configured this way.
It appears to be a way around the broken code at the moment. That said, well
done on the release!

*** Bug 5438 has been marked as a duplicate of this bug. ***

Ok. Since "my" report is closed, I will post here:

Now, after recompiling the X server and the driver without -z now, heres the new
message:

dlopen: /usr/lib/xorg/modules/nv_drv.so: undefined symbol: vgaHWInit


What can I do?

Thank you

(In reply to comment #7)
> dlopen: /usr/lib/xorg/modules/nv_drv.so: undefined symbol: vgaHWInit

Any module that gives you that message has been miscompiled, guaranteed.

In reply to Comment 8:

My gcc compiler:

CFLAGS="-march=athlon-xp -Os -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"

[ebuild   R   ] x11-drivers/xf86-video-nv-1.0.1.5  0 kB

What else can I do?
(using Gentoo)

Thank you

*** Bug 5880 has been marked as a duplicate of this bug. ***

(In reply to comment #9)

> What else can I do?

You must do an "emerge -e world" after you have changed your gcc version.

I did, and that fixed the unresolved symbols for me.

A hint: do and "emerge -pve world" and save the output to a file.  Now, if you
encounter an error during your emerge, you don't have to start from the
beginning, but can use the file to see the names of the packages still in need
of re-emerge.

Remember to include the versions, if you ever need to use the saved list.

Or you can simply learn the meaning of "emerge --resume" or "emerge --resume
--skipfirst"

I did, and it helped me a lot.

Hey,
I did a full emerge -e system and then a emerge xorg-x11.

But still no changes, I still get the "VgaHWInit" unresolved Symbol...

What else can I do?

Thanks

Join the dri-users list, and post your issues there. This was about a bug in X
on hardened systems. AFAICT you are not running a hardened system, and aiming
your comments at ajax or me. Ask a lot more people on the dri-users list.

The most probable issue is that gcc versions differ, i.e. the DRI binaries you
installed were compiled with one version of gcc, whereas the distro you are
using is compiled with another. What has that got to do with dlloader problems
on hardened systems?

(In reply to comment #13)

> I did a full emerge -e system and then a emerge xorg-x11.

And you were told to do a full emerge -e world.  No wonder it doesn't work.

The problem is not gcc.  It is the binaries compiled using it.  You must
recompile them all with your new gcc version.  That means the world set.  The
system set is not enough, and it has nothing to do with the fact that the system
set includes gcc.  I'll now leave this bug report alone.  All Gentoo users, take
heed!

>This was about a bug in X
>on hardened systems. AFAICT you are not running a hardened system, and aiming
>your comments at ajax or me.

The reason why I am posting here is because of comment number 6.

My bug was marked as a duplicate of this one...So I'm posting here...

Now I did a full emerge -e world. But there is no improvement.

I still get undefined symbol: vgaHWUnmapMem although it isn't vga_drv.so but
nv_drv.so

What else can I do?

I have Nvidia GeForce2 Ti, very old, but good.

The card is still supported, isn't it?

Thanks

Tobi

Updated to 3.4.6:

emerge -e system
emerge -e xorg-x11
emerge -e world
emerge -e xorg-x11

--> Still the same.

What about my graphic card? Maybe it is too old?
GeForce2 Ti

Thanks

(In reply to comment #17)
> Updated to 3.4.6:
> 
> emerge -e system
> emerge -e xorg-x11
> emerge -e world
> emerge -e xorg-x11
> 
> --> Still the same.

Whatever is going wrong here is completely a gentoo and/or configuration issue.
 There is _nothing_ in the code or the default build system that would require
vgaHWInit to be resolvable at dlopen time.

> What about my graphic card? Maybe it is too old?
> GeForce2 Ti

Age is irrelevant.  The nv driver can handle geforce2 cards just fine.  The
problem is your toolchain.

USE-Flag +dri -3dfx helped.
Thanx for everything