Failing to build PHP 8.4.5 from source

[abcbarryn]

Description

make: *** No rule to make target 'php-8.4.5/ext/date/lib/parse_date.c', needed by 'ext/date/lib/parse_date.lo'. Stop.

I am attempting to compile https://secure.php.net/distributions/php-8.4.5.tar.xz

If I manually create parse_date.c by running
re2c parse_date.re >parse_date.c
the compilation continues, but shouldn't the Makefile be doing this? Also, other .re files seem not to be generating their .c files. I did not have this issue when building PHP 8.2.

PHP Version

PHP 8.4.5

Operating System

SuSE Linux

[devnexen]

Hi, can you describe all the steps you went through once you extracted the archive ?

[abcbarryn]

I think I found the bad assumption in my .spec file...

# get parsers regenerated
for parser in $(find -type f -name "*.re");do
    rm -v ${parser%.*}.c
done

But really shouldn't the Makefile regenerate them? It used to for version 8.2.

[abcbarryn]

PS: I manually rebuilt the .c files from the .re files for now by adding this script:

    for refile in `find . -type f -name '*.re' -print`
    do
        dir=`dirname "$refile"`
        basefile=`basename "$refile" .re`
        if [ ! -e "$dir/$basefile.c" ]
        then
            re2c "$refile" >"$dir/$basefile.c" || re2c -c "$refile" >"$dir/$basefile.c"
        fi
    done

The Makefile should do this though, it used to on 8.2. If the .re files are not the source files anymore and it is intended to use and update the .c files directly then the .re files should probably be removed so someone else doesn't try to use them.

[devnexen]

Are you doing a custom build workflow ? e.g. not using buildconf

[abcbarryn]

I am using the spec file I used to build 8.2, but I changed the version to 8.4.5 so it loads the 8.4.5 tar source file. Like I said, it removes the .c files generated by re2c expecting Make to rebuild them. In 8.2, it does, in 8.4.5, it does not.

[iluuu1994]

ext-date commits the generated parser file. Hence, there shouldn't be a reason for you to regenerate it. Your spec file seems to be too eager. Changes to the ext/date/lib/parse_date.re file would need to be upstreamed to https://github.com/derickr/timelib anyway, so it shouldn't be modified directly.

Edit: Just to expand on this:

Like I said, it removes the .c files generated by re2c expecting Make to rebuild them. In 8.2, it does, in 8.4.5, it does not.

That's confusing, because I don't think the build process has really changed in that regard.

[abcbarryn]

It is confusing. If those source files are not meant to be used in the build process, why are they in the source folder? Why did the earlier version of PHP rebuild them? If the files are going to be included in the source folder, then at least the process to rebuild them should be documented and probably included in the generated Makefile, otherwise maybe move these files to a documentation folder, but then the spec files will need updating for various Linux distributions.

[iluuu1994]

I meant it's confusing that it would have worked in 8.2. The build process did not change, the .c file has been committed forever, and I can't see config0.m4 ever having regenerated the parser.

https://github.com/php/php-src/commits/master/ext/date/config0.m4

[abcbarryn]

So I have shell script that regenerates them. Should the spec file keep doing that, or should I be using the c files and not regenerating them? It definitely did work in 8.2 though. Don't ask me how, but I only ran into a problem with this in 8.4.

[iluuu1994]

Well, we don't build PHP for distributions. They do it themselves. The "official" way to build PHP is to download the tar file from the website, which includes the generated parser files. Hence, you don't need to regenerate the parsers at all, we do that before producing the tar file. Realistically, distributions do a bunch of things I'm not aware of, like regenerate parser files to match specific versions of re2c/bison. I've never been a release manager, so maybe somebody who is (/cc @derickr @bukka) can answer, but it's indeed true that from our side, it is not really expected/necessary to delete and regenerate these files.

[abcbarryn]

Is it ever desirable to regenerate them? Should I remove that procedure from the spec file?

[bukka]

Hmm I can't see any issue. I just did:

wget https://secure.php.net/distributions/php-8.4.5.tar.xz
tar -xf php-8.4.5.tar.xz
./configure
make -j10

Can you paste your steps?

You you shouldn't run buildconf on those source (use GH source directly if you want to do that) so nothing should be regenerated - (configure is already there).

[bukka]

Is it ever desirable to regenerate them? Should I remove that procedure from the spec file?

Yes remove it, you should not be regenerating anything.

[bukka]

Unless you are applying some extra patches that would require regeneration ofc

[bukka]

But again for such case it's better to use source directly from GitHub as we might remove some pre-built steps from distribution sources eventually.

[iluuu1994]

@bukka The removal of the parser files is apparently part of the RPM spec. It's not part of our build. OP was asking whether the parser shouldn't be regenerated on make. I have no idea why the RPM file removes those, but it doesn't seem like the intended way. Maybe they want to have the parser generated from the exact re2c version they're distributing.

[bukka]

It should not be be regenerating them. I think RPM is under OP control so they should just modify accordingly.

Of course if they are doing some extra patching, then they might need to regenerate them but it's really up to them to make it work correctly. And as I said for regenerating it is better to use source from the repository as we strip some files in the distributed tarball so it might not eventually work for them.

[abcbarryn]

I found out what caused this. The vendor (SuSE/Novell) had added a patch to the Makefile to rebuild the .c files from the .re files. That patch fails to apply on 8.4. I don't know why they wanted to do that though. Anyway, I fixed my copy of the spec file so it works with 8.4.5.

[iluuu1994]

Great! Thanks for letting us know.

[abcbarryn]

Can I get a little attention on another unrelated issue? :) #17770
#17770