Re: Issues with instdso.sh, build-1/libtool (and perhaps gnu.libtool)

[Michael Felt]

On 2/9/2018 6:02 AM, William A Rowe Jr wrote:
I will continue to work with you on this.  The horrors I'm confronting 
in other upstream projects... Ugh...


Please delete apr from your post to list. Unless they understand the 
purpose of doing so, it is a stupid build chain to reference, an 
exusible one is httpd's.

no longer included...


The httpd project is probably the wrong list to address you php concerns,

historically, php has always pointed at httpd - however...
but I'm ok with our helping you once or twice more. Good luck in your 
efforts;
I think I figured it out: See https://bugs.php.net/bug.php?id=63182 
(opened in 2012!!, and nothing. Older ones as well, but maybe they 
closed that one ;)


For the weary: looks like: ancient libtool components (1.5.26, from 
2008) and logic that might have almost been correct in 2008 (I have 
actually had issues since php-4.0.4, and always libtool related).


My "fix" - while it gets the jobs done (finally) - it does not mean it 
is "ASF" caused. My apologies - and thanks! for the hints that got me 
looking the right area (over 100k lines in php configure - sigh).


Anyway - issue is closed - here - as far as I am concerned.

Best regards,

Michael




On Feb 8, 2018 4:19 PM, "Michael Felt" > wrote:




On 07-Feb-18 19:40, William A Rowe Jr wrote:

Is the sapi compiled against libtool etc. from httpd? Or is it
using the
configure logic shipped with the php package?

The sapi is compiled using php configure, etc. The install part
uses instdso.sh and apxs, instdso.sh, iirc calls the libtool built
with/by apr.

In any case, asking httpd/apr to conform to the autoconf/libtool
packaging of php, which was built using its own flavor of the
toolchain
seems inconsistent.

As I tried to say, this is something I have been trying to get
understood by whoever.
Going with your idea re: php use of the toolchain - maybe they do
something wrong, read unexpected, in the way the library_name
variable is defined. And I also wonder, new idea, maybe I need to
use the libtool argument (must look it up) to say shared library
is not aix, but svr4 style. That might fix the .la contents.

So, thx for the thoughts!



It seems foolish to ask httpd-apxs to be the install tool of
the libphp5
binary. These are two different packages with two different
sets of
tooling. If you simply fix the make install to point to the
build/install.sh
tool of php, does it all work?



On Wed, Feb 7, 2018 at 8:50 AM, Michael
mailto:aixto...@felt.demon.nl>> wrote:

a) It has been a hard climb to get httpd-2.4.29 to build
using the latest
apr and apr-util. Still researching what that is (might be
expat related -
embedded versus external, still searching). Anyway,
working with apr-1.5.2 I
was at least able to get httpd-2.4.29 to build so I could
proceed to my
other "forever" hassle.

b) the forever "hassle": over the years (the first time I
posted "a bug may
be as far back as 2010", not bothering to post before then
(or it was
working??) - was getting "make install" to work for PHP.

c) PHP stated correctly - not them - would be instdso.sh.
Also posted, but
not conclusive. I hacked at instdso - as it knew what to
remove (rm -f) but
did not install. I just hard-wired it to copy the file,
if, at the end, it
was not there. With that, the chmod command that follows
instdso.sh works.

Quick History, better review:

Currently:

root@x065:[/data/prj/php/php-5.3.29]make install-sapi
Installing PHP SAPI module:       apache2handler
         /data/prj/php/src/php-5.3.29/build/shtool mkdir
-p /opt/bin
         if test ! -r
/data/prj/php/php-5.3.29/libs/libphp5.so; then  for i
in 0.0.0 0.0 0; do  if test -r
/data/prj/php/php-5.3.29/libs/libphp5.so.$i;
then  ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i
/data/prj/php/php-5.3.29/libs/libphp5.so; break;  fi; 
done; fi
         /data/prj/php/src/php-5.3.29/build/shtool mkdir -p
'/opt/httpd/libexec' &&
/data/prj/php/src/php-5.3.29/build/shtool mkdir -p
'/var/httpd/etc' && /opt/httpd/bin/apxs -S
LIBEXECDIR='/opt/httpd/libexec'
-S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la

Use of uninitialized value in concatenation (.) or string at
/opt/httpd/bin/apxs line 222.
/var/httpd/build/instdso.sh
SH_LIBT

Re: Time for 2.4.30? (Was: Re: 2.4.x STATUS needs you!)

[Nic Jansma]

Are there still plans to push for a 2.4.30 soon?  There's a couple bug 
fixes in it that I'd love to have in the official builds!


Thanks,

- Nic

On 2018/01/04 12:43:12, Jim Jagielski  wrote:
> As we get settled into the new year, it seems a good time>
> to think about a 2.4.30 release in the coming week or>
> so. Lots of good stuff currently in 2.4.30-dev and even>
> more good stuff in STATUS awaiting a single vote!>
>
> Let's see if we can clean-up STATUS, get 2.4.30-dev into>
> fantastic shape, and "commit" to doing a release no later>
> than mid Jan.>
>
> I volunteer to RM and/or help someone else RM.>
>

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[Yann Ylavic]

On Tue, Feb 13, 2018 at 3:19 PM, Graham Leggett  wrote:
>
> For the hostname, the field only has to be 256 characters long (because
> RFC1035 says it must be) and that’s manageable. I have created a patch to do
> this and it works for me.

Is it checked-in (can't see it)?


Thanks,
Yann.

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[Yann Ylavic]

On Tue, Feb 13, 2018 at 3:19 PM, Graham Leggett  wrote:
>
> Another option for the name is to store a URL prefix length and a hash of
> the prefix. If the hash of the prefix matches, we have a match. Would this
> work, would it be too expensive to hash on every hit, would it be safe
> enough?

It could work for prefix equality (with a keyed hash function like
siphash to avoid collision forgery), though hashing every URL
(possibly multiple times, for each different configured length) might
be more costly than the current strncmp.

But I suppose that the main issue is for regex matchings ("ProxyPass
~" and ProxyPassMatch)...


Regards,
Yann.

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[William A Rowe Jr]

On Tue, Feb 13, 2018 at 8:19 AM, Graham Leggett  wrote:
> On 09 Feb 2018, at 7:12 AM, William A Rowe Jr  wrote:
>
> [Why] would you compare 8192 byte strings as identifiers?
>
> I just checked the code, and as I suspected the “name” field isn’t a name,
> or an identifier, it’s actually a URL prefix.

Ah ha!

> When a balancer is found to match, the “balancer:foo” is removed, and
> replaced by the name, with the rest of the URL postfixed to it.
>
> As you can see - we’re currently arbitrarily limiting the length of the URL
> prefix to 256 characters, because 640k is big enough for everybody.

Got it. I had misunderstood, thanks for clarifying.

Must this replacement be stored in a fixed SHM buffer? Or can this
be stored in the member data in pconf, in its minimal buffer length?
We might lose display details from a prior graceful restart generation.
Guess I need to examine the dynamic reconfig feature set.


>> On Feb 8, 2018 2:39 PM, "Jim Jagielski"  wrote:
>>>
>>> Another, much more extensive and intrusive fix would be to create
>>> each ind field dynamically and tuck away in the  proxy_worker_shared
>>> struct the SHM field to be attached to which holds the actual dynamically
>>> allocated string. Better on SHM usage (our current usage is sloppy
>>> regarding
>>> SHM utilization due to the fixed char arrays, most of which aren't
>>> full) but more complex in other ways.
>>>
>>> Idea would be to use the actual name and generate a hash from
>>> that, use the hash as the SHM filename, create the SHM using
>>> that filename (hash) to dynamically allocate the host string
>>> and then store in proxy_worker_shared the hash (filename) used.
>>> Attach to that SHM as needed.
>>>
>>> Cleanup would need some thought…
>
> Another option for the name is to store a URL prefix length and a hash of
> the prefix. If the hash of the prefix matches, we have a match. Would this
> work, would it be too expensive to hash on every hit, would it be safe
> enough?

> For the hostname, the field only has to be 256 characters long (because
> RFC1035 says it must be) and that’s manageable. I have created a patch to do
> this and it works for me.

I'm ok with comparing the 256 characters of the URL, although
a hash could be a great optimization, hashing is already a key
asset of Maglev LB; https://research.google.com/pubs/pub44824.html

Re: BalancerMember and RFC1035 compliance - BalancerMember worker hostname (65-character.long.DNS.name.com) too long

[Graham Leggett]

On 09 Feb 2018, at 7:12 AM, William A Rowe Jr  wrote:[Why] would you compare 8192 byte strings as identifiers?I just checked the code, and as I suspected the “name” field isn’t a name, or an identifier, it’s actually a URL prefix.When a balancer is found to match, the “balancer:foo” is removed, and replaced by the name, with the rest of the URL postfixed to it.As you can see - we’re currently arbitrarily limiting the length of the URL prefix to 256 characters, because 640k is big enough for everybody.On Feb 8, 2018 2:39 PM, "Jim Jagielski"  wrote:Another, much more extensive and intrusive fix would be to create
each ind field dynamically and tuck away in the  proxy_worker_shared
struct the SHM field to be attached to which holds the actual dynamically
allocated string. Better on SHM usage (our current usage is sloppy regarding
SHM utilization due to the fixed char arrays, most of which aren't
full) but more complex in other ways.

Idea would be to use the actual name and generate a hash from
that, use the hash as the SHM filename, create the SHM using
that filename (hash) to dynamically allocate the host string
and then store in proxy_worker_shared the hash (filename) used.
Attach to that SHM as needed.

Cleanup would need some thought…Another option for the name is to store a URL prefix length and a hash of the prefix. If the hash of the prefix matches, we have a match. Would this work, would it be too expensive to hash on every hit, would it be safe enough?For the hostname, the field only has to be 256 characters long (because RFC1035 says it must be) and that’s manageable. I have created a patch to do this and it works for me.Regards,Graham—