graphics/png does not compile with gcc 4.5.1

Anonymous swell.k at gmail.com
Sun Jul 11 15:26:58 UTC 2010


"b. f." <bf1783 at googlemail.com> writes:

[...]
> 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,

Did you miss ports/148196? ld(1) ignores libmap.conf and will try to
link from libs in /usr/lib before $LOCALBASE/lib if it can unless you
alter linker hints. For any lib specified with `-l' I don't think even
hints are used.

> 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.

I don't think any suid/sgid app invoke gcc/ld during build. Besides,
libmap.conf won't affect gcc/ld because they're statically linked. OTOH,
smth like COMPILER_PATH=$LOCALBASE/bin has more chance breaking build in
an obscure way.

>
> 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.

The order of paths in linker hints makes that unlikely. And direct
linking requires `-L' option anyway except for gcc specific libs.

> (We are still eagerly awaiting this or an equivalent
> sandbox "safe rebuild" option in ports-mgmt/portmaster.  ;) )

I'd also like PATH overriding be put inside such a sandbox. While trying
to outsmart user portmaster makes using cc/ld wrappers harder.


More information about the freebsd-ports mailing list