DragonFly BSD
DragonFly users List (threaded) for 2012-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Top ten interesting broken packages (Volunteers?)


From: John Marino <dragonflybsd@xxxxxxxxx>
Date: Wed, 03 Oct 2012 23:46:19 +0200

On 9/18/2012 05:44, Mike Small wrote:
> John Marino<dragonflybsd@marino.st>  writes:
>
>> 01.  Emacs 24        (editors/emacs24 + editors/emacs24-nox11).
> ...
>> Problems with package:
>> 01.  build utility "temacs" segfaults
>
> This was caused by the C runtime startup objects not being linked (the
> link command used -nostdlib). There wasn't any _start symbol to be
> found, so ld threw up its hands and settled on the beginning of .text
> for the entry point. The only thing there was the puts function IIRC.
>
> My attempt at a fix is in the url at the end of this email. I don't know
> much about the c runtime startup process and just took the word of
> gcc -v on what was necessary:
>
> /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc44/crtbegin.o {application modules} -lgcc -lc -lgcc /usr/lib/gcc44/crtend.o /usr/lib/crtn.o
>
> To avoid hard coding the gcc44 directory I used
> $CC --print-libgcc-file-name to indirectly derive the paths of the two
> modules in the gcc subdirectory. Not sure what should be done here to
> support clang.
>
> Some of the other operating systems, including FreeBSD, that you see
> nearby in the first case statement in the diff link in a file called
> pre-crt0.o from the emacs distribution. I don't think this is needed so
> I left it out. All it does is define the symbol data_start, I guess to
> mark off the beginning of the data segment. But if you look at where
> that's used it isn't involved at all by the elf version of the unexec
> image dump code, and its use is prevented in start_of_data() in
> vm-limit.c by virtue of the BSD_SYSTEM macro being defined.
>
> Version 24.2 looks like it applied the security patch that was in
> patch-lisp_files.el so I've removed that file.
>
> Last of all, pkgsrc now has newer versions of autoconf and automake than
> were used to generate the configure script, so this patch includes a
> large diff to `configure' because of all the macro changes, as well as a
> new aclocal.m4. Is that how autotools updates should be handled or would
> it have been better for me to get the old autoconf 2.68 to regenerate
> configure with minimal changes?
>
> http://www.panix.com/~smallm/pkgsrc_dfly_emacs24_segfault.patch.gz


Hi Mike,
Thanks for the patch.  I verified that emacs24 and emacs24-nox build on 
i386 and I committed it here:
http://pkgsrc.se/files.php?messageId=20121003213243.1983A175DD@cvs.netbsd.org

I meant to credit you in the commit message for the patch, but I forgot 
to do it.  In a couple of days I'll ask for this commit to get "pulled 
up" to 2012Q3 branch.

Nice work!
John



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]