Date: Mon, 11 Mar 2013 12:12:40 -0400 From: Ilya Kaliman <ilya.kaliman@gmail.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Linking produces unusable executable Message-ID: <CA%2BSmX2CgRGx70vRyGuwv9S%2BSZmxrbjSRQ7X92V5yUTDC%2B4jWQg@mail.gmail.com> In-Reply-To: <20130311055822.GK3794@kib.kiev.ua> References: <CA%2BSmX2BCY=ySp-1aXHRHWa2LbCb31vBGvu4ivwyzAi2M4S_ujQ@mail.gmail.com> <20130311055822.GK3794@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks a lot for the help! Increasing kern.maxtsiz solved the problem. Best, Ilya. On Mon, Mar 11, 2013 at 1:58 AM, Konstantin Belousov <kostikbel@gmail.com> wrote: > On Sun, Mar 10, 2013 at 09:00:02PM -0400, Ilya Kaliman wrote: >> Hello, hackers! >> >> I have a strange problem with a big executable. I have a piece of scientific >> software and some C++ module in it with a LOT of template code. When compiled >> this module produces 450 MB archive file (w/o debugging symbols). Now, when I >> compile the program without this module everything works perfect. With this >> module turned on the linker produces an executable (around 180 MB in size) >> without any errors or warnings. But when I try to start the final program zsh >> just says: abort. ldd on this exe says: ./a.out: signal 6. >> >> I watched the memory consumption during linking and it doesn't seem to exhaust >> all available memory (the linker seem to stop allocating on around 2 GB). I've >> also tried to enable --no-keep-memory for ld with no luck - linking still >> produces no errors but the resulting executable is unusable. >> >> I've tried it on 9.1 and 10-CURRENT with both gcc/g++/ld from the base system >> and from ports (gcc 4.7.3, binutils 2.23.1) and with clang. >> >> I've tried to build some of the bigger ports like chromium (just in case): >> all works fine. >> >> Everything works on linux though (with the same gcc/ld). With debugging symbols >> the exe is around 1GB, without them its around 200MB. Works fine in every case >> with different optimization levels. >> >> Any ideas how to solve this? > > For start, it would be nice to provide some useful information together > or even instead of the long story. > > What is the architecture ? Show at least the output of the size(1) on > the final binary. Show exact shell message on the attempt of the binary > run. Show the ktrace/kdump of the start attempt. > > As a guess, look at the sysctl kern.maxtsiz and compare it to the text > size reported by the size(1). The same for the initialized data segment > and kern.maxdsiz.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BSmX2CgRGx70vRyGuwv9S%2BSZmxrbjSRQ7X92V5yUTDC%2B4jWQg>