prelink (http://www.die.net/doc/linux/man/man8/prelink.8.html) screws up some D executables built by DMD or GDC v0.17, which is a potentially large problem because it is installed to run automatically by default on a lot of Linux systems (for most common system bin directories) from what I gather.

I've seen odd problems apparently caused by prelink on C++ executables too (that's what prompted me to try it w/ D exe's), so the wisdom of having prelink run by default seems dubious at best. It's purely cause-and-effect for me because I haven't the time to dig into exactly what is happening to cause the problems.

On Fedora systems a driver script is setup in /etc/cron.daily.

I've been able to prevent the prelink by using the -L-pie switch (http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html)

However, I'm not real familiar with exactly what the consequences of -pie will be so I'm not recommending it, just putting this info. out there in the hopes that someone can explain the problem and work toward a fix.

Obviously, this could have big consequences as more and more D executables make their way out into the wild in system bin directories.

Anyone?

Thanks,

- Dave

Dave wrote:
> 
> prelink (http://www.die.net/doc/linux/man/man8/prelink.8.html) screws up some D executables built by DMD or GDC v0.17, which is a potentially large problem because it is installed to run automatically by default on a lot of Linux systems (for most common system bin directories) from what I gather.
> 
> I've seen odd problems apparently caused by prelink on C++ executables too (that's what prompted me to try it w/ D exe's), so the wisdom of having prelink run by default seems dubious at best. It's purely cause-and-effect for me because I haven't the time to dig into exactly what is happening to cause the problems.
> 
> On Fedora systems a driver script is setup in /etc/cron.daily.
> 
> I've been able to prevent the prelink by using the -L-pie switch (http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html) 
> 
> 
> However, I'm not real familiar with exactly what the consequences of -pie will be so I'm not recommending it, just putting this info. out there in the hopes that someone can explain the problem and work toward a fix.
> 
> Obviously, this could have big consequences as more and more D executables make their way out into the wild in system bin directories.
> 
> Anyone?

What actually happens to the executable ~ does it just die? Worse?

kris wrote:
> Dave wrote:
>>
>> prelink (http://www.die.net/doc/linux/man/man8/prelink.8.html) screws up some D executables built by DMD or GDC v0.17, which is a potentially large problem because it is installed to run automatically by default on a lot of Linux systems (for most common system bin directories) from what I gather.
>>
>> I've seen odd problems apparently caused by prelink on C++ executables too (that's what prompted me to try it w/ D exe's), so the wisdom of having prelink run by default seems dubious at best. It's purely cause-and-effect for me because I haven't the time to dig into exactly what is happening to cause the problems.
>>
>> On Fedora systems a driver script is setup in /etc/cron.daily.
>>
>> I've been able to prevent the prelink by using the -L-pie switch (http://www.linuxfromscratch.org/hlfs/view/unstable/uclibc/chapter02/pie.html) 
>>
>>
>> However, I'm not real familiar with exactly what the consequences of -pie will be so I'm not recommending it, just putting this info. out there in the hopes that someone can explain the problem and work toward a fix.
>>
>> Obviously, this could have big consequences as more and more D executables make their way out into the wild in system bin directories.
>>
>> Anyone?
> 
> What actually happens to the executable ~ does it just die? Worse?
Some exe's segfault under some conditions, some don't. All I can say so far, but there is a direct cause-and-effect: compile and run it, and the exe works fine all day long, prelink the same executable and it crashes.

Here's some code:

import std.stdio, std.string, std.outbuffer;

int main(char[][] args)
{
    int n = args.length > 1 ? atoi(args[1]) : 1;

    OutBuffer ob = new OutBuffer();

    for(int i = 0; i < n; i++)
    {
        ob.write("hello\n");
    }

    writefln(ob.toString().length);

    return 0;
}

# dmd -O -inline -release strcat.d
# ll strcat
# for x in `seq 1 10`; do strcat 1000000; done
# /usr/sbin/prelink ./strcat
# ll strcat
# for x in `seq 1 10`; do strcat 1000000; done

Note that running a prelinked strcat with 10_000 doesn't segfault, howerver it does when running it with 1_000_000.

Compiling phobos with -g -release says it crashes in std/outbuffer.d:92. Run with just -g and it crashes at internal/invariant.d:16.

I have a couple of other examples of prelinked D executables that also segfault, and those don't use OutBuffer so I don't think the problem can be isolated to that in conjunction with prelink.

Something in the exe's is apparently getting hosed-up by prelink.

- Dave