Date: Sun, 11 Jul 2010 13:46:53 +0000 From: "b. f." <bf1783@googlemail.com> To: freebsd-ports@FreeBSD.org Cc: Anonymous <swell.k@gmail.com>, Doug Barton <dougb@FreeBSD.org> Subject: Re: graphics/png does not compile with gcc 4.5.1 Message-ID: <AANLkTimUd-yh-HFsYTDZxP0XsdIywu2Oks0LY6Pz1lYS@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
> Anonymous <swell.k at gmail.com> writes: > > > Doug Barton <dougb at FreeBSD.org> writes: > > > >> readelf -s /lib/libc.so.7 | fgrep __stack_chk_fail > >> 952: 00028060 26 FUNC GLOBAL DEFAULT 10 __stack_chk_fail@@FBSD_1.0 > >> 1457: 00028060 26 FUNC GLOBAL DEFAULT 10 __stack_chk_fail_local at FBSD_1.0 > > > >> 45: 000ecec0 29 FUNC LOCAL HIDDEN 10 __stack_chk_fail_local > > > > I don't see such HIDDEN symbol on i386/amd64 snapshots from Jun 30 at > > allbsd.org. Can you *install* libc.so.7 from there and try again? > > Did it help? Based on result from above suggestion either my guesses > were incorrect[1] or you have messed up environment/make.conf[2]. > To debug the latter you'd have to bisect your own build configuration. > > [1] the problem is reproducable on libc from snapshot > [2] ... *not* reproducable ... > > > > >> 1542: 00028060 26 FUNC GLOBAL DEFAULT 10 __stack_chk_fail > >> 2047: 00028060 26 FUNC GLOBAL DEFAULT 10 __stack_chk_fail_local at FB I have not attempted to reproduce this particular problem, but some of these symbols in the base system libraries appear similar to others I have seen when parts of the base system are built while remapping the base system compiler libraries to their counterparts in lang/gcc4* ports via libmap.conf(5), as recommended in, for example, http://www.freebsd.org/doc/en_US.ISO8859-1/articles/custom-gcc/configuring-ports-gcc.html Despite claims of 100% backwards-compatibility for these libraries, this remapping will have some consequences, so you may want to check if you have disabled the remapping while building/installing the base system, which I would recommend. And to be on the safe side, I would do this by editing or temporarily moving libmap.conf, rather than by setting LD_LIBMAP_DISABLE in the build/installation environment, to avoid potential problems with sgid/suid binaries. Also, when updating or reinstalling ports, I would first deinstall the old versions (including old versions of the shared libraries that may be in *compat*) before rebuilding the new versions, to avoid any linking problems. (We are still eagerly awaiting this or an equivalent sandbox "safe rebuild" option in ports-mgmt/portmaster. ;) ) Regards, b.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimUd-yh-HFsYTDZxP0XsdIywu2Oks0LY6Pz1lYS>