[squid-dev] squid-3.5.7 -- xstrerror missing

[Amos Jeffries]

On 17/08/2015 1:15 p.m., Linda W wrote:
> Amos Jeffries wrote:
> 
>> So there is absolutely *no* portability symbols defined. Not one.
> ---
> It's then gcc/ldd setup:
> 
> If I take out the -flto option from CFLAGS (I can leave in the
> -fuse-linker-plugin, but I don't think it can do anything in the absence of
> -flto) it links.
> 
> While it says if you don't use -flto and -fuse-linker-plugin to use
> -fwhole-program --- then I get a different class of errors -- items defined
> but unused -- the opposite of the undefined case.
> 
> To be clear "-flto" was in my CFLAGS (and LDFLAGS) -- if I take that out
> it links...   But I wonder what the -with-flto, etc options that squid
> has in its configure do if I don't specify the -flto option in CFLAGS..
> 
> But that's it (dunno if the binary works or not, but can try that next).
> 
> Sorry, but I find the squid build among the more complicated things I
> build myself (but it doesn't have the worst config procedure)  I admit
> the new samba4 build looks daunting... but samba3 was a piece of cake.
> 
> One of the main confusions -- on some of the switches if you
> DON't disabled them, it will try to build all the helpers in a dir..  Vs.
> others, will build none -- unless they are specified.   That wasn't @ fault
> in the final analysis here, but that certainly could be a bit more
> consistent?

I've tried to make it simple to read the ./configure --help output by
following the auto-tools guidelines:

* --enable/--disable for features and config default values.

* --with/--without for library and system default paths.

* if it lists --enable/--with then the feature is off by default.

* if it lists --disable/--without then its on by default.

* options taking lists of helpers or module names are auto-detect by
default, but setting "none" will disable.

There may be some inconsistency with the options that set a defaut value
for things. But that should be all in the latest releases.


> 
> Try adding "-flto" to your CFLAGS and see how it affects your build...vs
> -fwhole-program.  gcc manpage says if you aren't using the lto, to use
> the whole-program, so it can do best job/unit... but I just upgraded to
> the 4.9 series...so who know, may have some kinks.
> 
> Thanks for at least looking at this! 
> 

Thanks back to you for finding it in the end. I'm testing now to see if
I can replicate. There are some other custom flags related issues that
have been evading solution and this may be a good way to identify a bug
behind all of them.

Amos