On 30/09/15 23:23, Sean McGovern wrote: > On Wed, Sep 30, 2015 at 7:10 AM, Luca Barbato <[email protected]> wrote: > >> On 29/09/15 22:45, Sean McGovern wrote: >>> On Tue, Sep 29, 2015 at 4:26 AM, Luca Barbato <[email protected]> >> wrote: >>> >>>> On 29/09/15 02:24, Sean McGovern wrote: >>>>> --- >>>>> configure | 4 ++++ >>>>> 1 file changed, 4 insertions(+) >>>>> >>>>> diff --git a/configure b/configure >>>>> index 49643d6..efedc67 100755 >>>>> --- a/configure >>>>> +++ b/configure >>>>> @@ -3557,6 +3557,10 @@ case $target_os in >>>>> sunos) >>>>> SHFLAGS='-shared -Wl,-h,$$(@F)' >>>>> enabled x86 && SHFLAGS="-mimpure-text $SHFLAGS" >>>>> + # Even at extremely high optimization levels, >>>>> + # suncc refuses to inline functions when >>>>> + # debug mode is enabled. >>>>> + enabled_all suncc debug && disable symver >>>>> network_extralibs="-lsocket -lnsl" >>>>> # When using suncc to build, the Solaris linker will mark >>>>> # an executable with each instruction set encountered by >>>>> >>>> >>>> Disabling symbol version lets you inline and debug? >>>> >>>> lu >>>> ____ >>>> >>> >>> I'm having a hard time remembering the context for this patch -- I've had >>> this sitting in my local repo for at least 2 years, if not more. >>> >>> I have a vague memory of discovering this while working on a different >>> issue with either Martin or Mans. I think it had to do with some of our >>> inline assembly. >>> >>> It only seems to occur on the suncc though, gcc is unaffected. >> >> I do not have a solaris handy, could you please test what's happening >> with this mix? >> >> lu >> >> _ >> > > Currently, if I want to build shared libraries with suncc, I can complete > the build from the following command line: > > ./configure --disable-static --enable-shared --cc='suncc -m64' > --disable-debug > > If I remove --disable-debug, it complains about undefined symbols in > several libraries that are ff_ prefixed -- which makes sense as the linker > script is removing them from global scope. I'm not sure why this doesn't > affect the gcc build. > > This warrants further investigation on my end, but it is not a blocker on > patch 1/2. >
It isn't a blocker but would be nice to add a comment about it, if the problem is yet another internal symbol not-so-internal we should fix it asap. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
