Date: Sat, 29 Mar 2014 18:27:17 +0400 From: Dmitry Marakasov <amdmi3@amdmi3.ru> To: Dimitry Andric <dim@FreeBSD.org> Cc: freebsd-ports@freebsd.org Subject: Re: HEAD clang failures due to unknown arguments Message-ID: <20140329142717.GJ73879@hades.panopticon> In-Reply-To: <14D047DD-EE2F-4512-BC18-518B693CCD6B@FreeBSD.org> References: <20140329044342.GG73879@hades.panopticon> <73F477CA-6AF4-4217-AC81-730A5DED11D5@FreeBSD.org> <20140329124652.GH73879@hades.panopticon> <14D047DD-EE2F-4512-BC18-518B693CCD6B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Dimitry Andric (dim@FreeBSD.org) wrote:
> > I've just removed them and it worked. Or is there a reason for rpath to
> > system lib directory?
>
> It seems that -rpath is sometimes used gratuitously, indeed. Though it
> can sometimes be necessary, if shared libraries are installed into
> non-standard places, e.g. /usr/local/lib/myapp/libmyapp.so.
That I know. Just wanted to make sure that it's not really needed for
/usr/local/lib
> Also, not all systems have had /usr/local/lib in their default dynamic
> linker path. And I'm also not sure what happens if you attempt to set
> $LOCALBASE to something other than /usr/local/lib. :-)
>
> I tried that once, and I was not really happy with the results...
You should've probably just added YOUR_LOCALBASE/lib into ldconfig_paths.
I've had a jail in my tinderbox which used completely custom
PREFIX and LOCALBASE to catch hardcoded /usr/local's - it worked fine
and built almost all software (which it hadn't I've fixed).
> > What I plan to do is:
> >
> > ---
> > USES+= compiler:env
> >
> > .include <bsd.port.pre.mk>
> >
> > post-patch:
> > .if ${COMPILER_TYPE} == "clang"
> > @${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt
> > .endif
> > ---
> >
> > but what if next version of clang learns of this key?
>
> In this particular case, it will probably never support it. There are
> many options which a very specific to gcc (mostly for its optimizer),
> which make no sense for clang.
Again, my question is not tied to any spedific option. If gcc had
-fwhole-program and clang had -fclang-whole-program, there should be a
convenient way to do this. Making upstream do conditional checks is a
good thing, but if that was possible in all cases, we wouldn't have any
patches in the ports tree. In real world, unfortunately, ports tree is
mostly patches.
> > I'd like to have
> > something like
> >
> > .if ! ${COMPILER_SUPPORTED_ARGUMENTS:M-fwhole-program}
> > @${REINPLACE_CMD} -e 's|-fwhole-program||' ${WRKSRC}/CMakeLists.txt
> > .endif
> >
> > .if ${COMPILER_SUPPORTED_ARGUMENTS:M-malign-double}
> > CXXFLAGS+= -malign-double
> > .endif
>
> Now you are encoding the work of CMake and autoconf into the ports
> infrastructure? I am not sure if that is the proper way. However, I
> seem to remember there was also an effort to provide "global" autoconf
> and CMake preconfiguration, maybe this type of compiler-specific
> knowledge thing could be folded into that?
I don't see another way. For example, -R stuff comes from libiconv and
gettext:
---
LTLIBICONV="${LTLIBICONV}${LTLIBICONV:+ }-R$found_dir"
---
LTLIBINTL="${LTLIBINTL}${LTLIBINTL:+ }-R$found_dir"
---
To fix that, first we need to fix macros containing these lines, next
wait for new versions to be released, next wait for everybody to use
these versions. That's years for maintained software while there's also
unmaintained, and for that we need a way to deal with this in ports.
So dealing with that in ports, just checking ${COMPILER_TYPE} is not
future-proof, so we need something better, as I suggested.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140329142717.GJ73879>