Ned Ludd said:
> On Sun, 2005-05-29 at 15:02 +0200, Tóth Attila wrote:
>
>> Beside modifying profile symlink you shouldn't need "pic" and "pie"
>> flags in your make.conf any more.
>
> You need USE=pic if your going to use the hardened toolchain or you
> will be in a world of hurt. Take gzip for ex
> I've never been able to get mono to build with the hardened
> kernel extensions active. The problem, as you might have
> already deduced, is that mono violates some of hardened's
> protection bits -- specifically, the mono runtime tries to
> execute data as code. Once mono's installed you c
> /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld:
>
> ./.libs/libmono-static.a(domain.o): relocation R_X86_64_TPOFF32 against
> `a local symbol' can not be used when making a shared object; recompile
> with -fPIC
the linker told you the problem: some cod
On 30 May 2005 at 15:13, Chris S wrote:
[...]
> Thank you for your reply. This makes sense. I guess the problem is that
> I need to run .net as a service on an internet visible server. I do not
> however want to remove hardened just for the sake of .net support!
> Do you think it is possible to
[EMAIL PROTECTED] wrote:
what matters for letting mono run under PaX is that you have to exempt
it for runtime code generation. i don't know how apache/mono interact,
but you'll see it from the PaX kill logs and you'll have to paxctl -m
the affected process.
if it's apache itself (e.g., it uses
Chris S wrote:
Mike Edenfield wrote:
I've never been able to get mono to build with the hardened kernel
extensions active. The problem, as you might have already deduced, is
that mono violates some of hardened's protection bits -- specifically,
the mono runtime tries to execute data as code.
Mike Edenfield wrote:
You don't need to disable the GRSEC stuff to run mono -- only to build
it. Once it's build and in place in the right spot, you can disable
the memory protection bits just for the `mono` binary. You can either
put GRSEC into learning mode and build a profile that way, or
[EMAIL PROTECTED] wrote:
/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld:
./.libs/libmono-static.a(domain.o): relocation R_X86_64_TPOFF32 against
`a local symbol' can not be used when making a shared object; recompile
with -fPIC
the linker told you
Chris S wrote:
Under hardened-sources with gcc-vanilla I then emerged mod_mono and
restarted apache. I'm struggling a little with that, but the issue of
this thread has been "solved".
I now appear to have asp.net working under apache with mod_mono, on a
pure 64bit (hardened-built) gentoo s
I found out symlinking libtool-nofpic to libtool (which produces PIC
binaries) eliminates most of the relocations. I am able to build on
Gentoo either outside Portage or using my custom ebuild.
Just add "use x86 && has_pic && ln -sf libtool ${S}/libtool-nofpic"
right after econf. You can also comm
10 matches
Mail list logo
