Configure error cannot find php config please use with php config path

Setup config php error

The behaviour of these functions is affected by settings in php.ini .

Errors and Logging Configuration Options

For further details and definitions of the PHP_INI_* modes, see the Where a configuration setting may be set.

Here’s a short explanation of the configuration directives.

Set the error reporting level. The parameter is either an integer representing a bit field, or named constants. The error_reporting levels and constants are described in Predefined Constants, and in php.ini . To set at runtime, use the error_reporting() function. See also the display_errors directive.

The default value is E_ALL .

Prior to PHP 8.0.0, the default value was: E_ALL &

E_NOTICE &

E_STRICT &

E_DEPRECATED . This means diagnostics of level E_NOTICE , E_STRICT and E_DEPRECATED were not shown.

Note: PHP Constants outside of PHP

Using PHP Constants outside of PHP, like in httpd.conf , will have no useful meaning so in such cases the int values are required. And since error levels will be added over time, the maximum value (for E_ALL ) will likely change. So in place of E_ALL consider using a larger value to cover all bit fields from now and well into the future, a numeric value like 2147483647 (includes all errors, not just E_ALL ).

This determines whether errors should be printed to the screen as part of the output or if they should be hidden from the user.

Value «stderr» sends the errors to stderr instead of stdout .

This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).

Although display_errors may be set at runtime (with ini_set() ), it won’t have any effect if the script has fatal errors. This is because the desired runtime action does not get executed.

Even when display_errors is on, errors that occur during PHP’s startup sequence are not displayed. It’s strongly recommended to keep display_startup_errors off, except for debugging.

Tells whether script error messages should be logged to the server’s error log or error_log. This option is thus server-specific.

You’re strongly advised to use error logging in place of error displaying on production web sites.

Set the maximum length of log_errors in bytes. In error_log information about the source is added. The default is 1024 and 0 allows to not apply any maximum length at all. This length is applied to logged errors, displayed errors and also to $php_errormsg , but not to explicitly called functions such as error_log() .

When an int is used, the value is measured in bytes. Shorthand notation, as described in this FAQ, may also be used. ignore_repeated_errors bool

Do not log repeated messages. Repeated errors must occur in the same file on the same line unless ignore_repeated_source is set true.

Ignore source of message when ignoring repeated messages. When this setting is On you will not log errors with repeated messages from different files or sourcelines.

If this parameter is set to On (the default), this parameter will show a report of memory leaks detected by the Zend memory manager. This report will be sent to stderr on Posix platforms. On Windows, it will be sent to the debugger using OutputDebugString() and can be viewed with tools like » DbgView. This parameter only has effect in a debug build and if error_reporting includes E_WARNING in the allowed list.

If enabled, the last error message will always be present in the variable $php_errormsg .

If enabled, error messages will include HTML tags. The format for HTML errors produces clickable messages that direct the user to a page describing the error or function in causing the error. These references are affected by docref_root and docref_ext.

If disabled, error message will be solely plain text.

If enabled, turns off normal error reporting and formats errors as XML-RPC error message.

Used as the value of the XML-RPC faultCode element.

The new error format contains a reference to a page describing the error or function causing the error. In case of manual pages you can download the manual in your language and set this ini directive to the URL of your local copy. If your local copy of the manual can be reached by «/manual/» you can simply use docref_root=/manual/ . Additional you have to set docref_ext to match the fileextensions of your copy docref_ext=.html . It is possible to use external references. For example you can use docref_root=http://manual/en/ or docref_root=»http://landonize.it/?how=url&theme=classic&filter=Landon &url=http%3A%2F%2Fwww.php.net%2F»

Most of the time you want the docref_root value to end with a slash «/» . But see the second example above which does not have nor need it.

This is a feature to support your development since it makes it easy to lookup a function description. However it should never be used on production systems (e.g. systems connected to the internet).

The value of docref_ext must begin with a dot «.» .

String to output before an error message. Only used when the error message is displayed on screen. The main purpose is to be able to prepend additional HTML markup to the error message.

String to output after an error message. Only used when the error message is displayed on screen. The main purpose is to be able to append additional HTML markup to the error message.

Name of the file where script errors should be logged. The file should be writable by the web server’s user. If the special value syslog is used, the errors are sent to the system logger instead. On Unix, this means syslog(3) and on Windows it means the event log. See also: syslog() . If this directive is not set, errors are sent to the SAPI error logger. For example, it is an error log in Apache or stderr in CLI. See also error_log() .

File mode for the file described set in error_log.

Specifies what type of program is logging the message. Only effective if error_log is set to «syslog».

Specifies the filter type to filter the logged messages. Allowed characters are passed unmodified; all others are written in their hexadecimal representation prefixed with x .

• all – the logged string will be split at newline characters, and all characters are passed unaltered
• ascii – the logged string will be split at newline characters, and any non-printable 7-bit ASCII characters will be escaped
• no-ctrl – the logged string will be split at newline characters, and any non-printable characters will be escaped
• raw – all characters are passed to the system logger unaltered, without splitting at newlines (identical to PHP before 7.3)

This setting will affect logging via error_log set to «syslog» and calls to syslog() .

The raw filter type is available as of PHP 7.3.8 and PHP 7.4.0.

Specifies the ident string which is prepended to every message. Only effective if error_log is set to «syslog».

Источник

setup-config.php throws ‘WordPress database error Unknown column’

I’m trying to install WordPress on Ubuntu (more precisely, Ubuntu Mate 21.04 desktop 64b run in a VirtualBox VM)

Problem is that when I open my localhost WordPress installation for the first time and click through the famous 5-minute installer then as soon as I enter database details and click Submit the following error appears in /var/log/apache2/error.log :

[Sun Aug 08 18:37:28.141296 2021] [proxy_fcgi:error] [pid 19693:tid 140137111639616] [client 127.0.0.1:44772] AH01071: Got error ‘PHP message: WordPress database error Unknown column ‘wp_’ in ‘field list’ for query SELECT wp_PHP message: WordPress database error Incorrect table name » for query INSERT INTO « (`option_name`, `option_value`, `autoload`) VALUES (‘nonce_key’, ‘-l;6hq@?fr/*VUp9p_B^+,Aj/S8!j|#H%pIWy`0i!OXWQx3AuNwwPhK4‘, ‘no’) ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) made by wp_print_scripts, wp_scripts, WP_Scripts->__construct, WP_Scripts->init, do_action_ref_array(‘wp_default_scripts’), WP_Hook->do_action, WP_Hook->apply_filters, wp_default_scripts, wp_create_nonce, wp_hash, wp_salt, update_site_option, update_network_option, add_network_option, add_optionPHP message: WordPress database error Incorrect table name » for query INSERT INTO « (`option_name`, `option_value`, `autoload`) VALUES (‘nonce_salt’, ‘lz`4ap>SeckS-<*B;S>#DrQ5*MBa|G,_0>R0?fJruKs_o4J-+4C7

#ef?/&U?sh|’, ‘no’) ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`) made by wp_print_scripts, wp_scripts, WP_Scripts->__construct, WP_Scripts->init, do_action_ref_array(‘wp_default_scripts’), WP_Hook->do_action, WP_Hook->apply_filters, wp_default_scripts, wp_create_nonce, wp_hash, wp_salt, update_site_option, update_network_option, add_network_option, add_option’, referer: http://localhost/wp-admin/setup-config.php?step=1

Despite the error the installer seems to work fine and WordPress seems to be installed correctly, at least on the first glance.

However, since an error was logged during installation I’m worried that I can’t be sure that no subtle, hard to find problems linger that may cause trouble later.

Therefore I would like to ask if this error is safe to ignore or if it’s not then how to resolve it and how to install WordPress without it appearing?

The exact steps I did:

1. sudo apt install apache2 php-fpm php-mysql mariadb-client mariadb-server php-curl php-mbstring php-imagick php-zip php-xml
2. sudo mariadb , and then:
3. wget https://wordpress.org/latest.tar.gz
   tar -xzvf latest.tar.gz
   sudo cp -R wordpress /var/www/
   sudo chown -R www-data:www-data /var/www/wordpress/
4. Inside /etc/apache2/sites-available create file wordpress.conf with content:

sudo a2enmod proxy_fcgi setenvif rewrite
sudo a2enconf php7.4-fpm
sudo a2ensite wordpress
sudo systemctl restart apache2

Enter http://localhost/ in the browser, click through the installation script, when asked for database details enter the following:

Database Name: wordpress
Username: wordpressusername
Password: redacted
Database Host: localhost
Table Prefix: wp_

EDIT: I’m very sorry that when I posted this question it was a formatting mess 🙁 I hope I managed to fix this

• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .
• This topic was modified 1 year, 5 months ago by kmph .

Источник

configure: error: Cannot find php-config. Please use —with-php-config=PATH

by frank · February 17, 2021

checking for grep that handles long lines and -e. /usr/bin/grep
checking for egrep. /usr/bin/grep -E
checking for a sed that does not truncate output. /usr/bin/sed
checking for pkg-config. /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0. yes
checking for cc. cc
checking whether the C compiler works. yes
checking for C compiler default output file name. a.out
checking for suffix of executables.
checking whether we are cross compiling. no
checking for suffix of object files. o
checking whether we are using the GNU C compiler. yes
checking whether cc accepts -g. yes
checking for cc option to accept ISO C89. none needed
checking how to run the C preprocessor. cc -E
checking for icc. no
checking for suncc. no
checking for system library directory. lib
checking if compiler supports -R. no
checking if compiler supports -Wl,-rpath. yes
checking build system type. x86_64-pc-linux-gnu
checking host system type. x86_64-pc-linux-gnu
checking target system type. x86_64-pc-linux-gnu
configure: error: Cannot find php-config. Please use —with-php-config=PATH

Unsolvable !

If you notice above, I have already passed the —with-php-config path with the correct path, and the configure found php-config:

checking for pkg-config. /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0. yes

What more can I do ?

In the configure.log I see

configure:3774: error: Cannot find php-config. Please use —with-php-config=PATH

Let’s go see around line 3774:

So it runs directly the argument passed. They don’t want the path (directory) where php-config is located, they want to fullpath of the binary !

Solution

checking for gawk. gawk
checking for fileinfo support. yes, shared
checking for magic files in default path. not found
configure: error: Please reinstall the libmagic distribution

Источник

Description:
------------
I'm running php 5.0.4 (no option for it in PHP version?).  Here's what I did:

1. tar zxvfm Fileinfo-0.3.tgz (inside ext src directory)
2. mv Fileinfo-0.3 fileinfo
3. sh ../../scripts/phpize
4. ./configure --with-php-config=/etc/php.ini

The configure stops and I get this error: 

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether gcc and cc understand -c and -o together... yes
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
/etc/php.ini: line 1: [PHP]: command not found
/etc/php.ini: line 3: syntax error near unexpected token `;;'
/etc/php.ini: line 3: `;;;;;;;;;;;;;;;;;;;'
configure: error: Cannot find php-config. Please use --with-php-config=PATH

Expected result:
----------------
fileinfo should configure

Actual result:
--------------
Throws an error when attempting to configure when pointing to the php.ini file.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports

I would also like to compile this module statically but when I remove the old main php configure file and run ./buildconf --force in the php src directory, the --with-fileinfo flag isn't added to that configure file.

I figured out what the problem was.  I didn't know that for every new extension you add to php, you have to delete the previously compiled source and untar it again so it will detect the new extension.  It seems strange that the only time the php configure script will detect an extension is if it is newly untarred.

Sorry, but your problem does not imply a bug in PECL itself.  For a
list of more appropriate places to ask for help using PECL, please
visit http://pecl.php.net/support/ as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PECL.

--with-php-config should point to the php-config script not to php.ini

1 2012-03-27 16:55:36

2 Ответ от Hanut 2012-03-27 17:36:53

3 Ответ от Nikem79 2012-03-28 08:40:34 (изменено: Nikem79, 2012-03-28 08:49:17)

 ~/tmp/php-5.3.10/ext/mysqli]$ ./configure --with-php-config=/home/$USER/php/bin/php-config --with-mysqli=/home/$USER/php-5.3.10/ext/mysqli/
checking for egrep... grep -E
checking for a sed that does not truncate output... /usr/bin/sed
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ANSI C... none needed
checking how to run the C preprocessor... cc -E
checking for icc... no
checking for suncc... no
checking whether cc understands -c and -o together... yes
checking for system library directory... lib
checking if compiler supports -R... yes
checking build system type... i386-unknown-freebsd6.2
checking host system type... i386-unknown-freebsd6.2
checking target system type... i386-unknown-freebsd6.2
checking for PHP prefix... /home/partek2/php
checking for PHP includes... -I/home/partek2/php/include/php -I/home/partek2/php/include/php/main -I/home/partek2/php/include/php/TSRM -I/home/partek2/php/include/php/Zend -I/home/partek2/php/include/php/ext -I/home/partek2/php/include/php/ext/date/lib
checking for PHP extension directory... /home/partek2/php/lib/php/extensions/no-debug-non-zts-20090626
checking for PHP installed headers prefix... /home/partek2/php/include/php
checking if debug is enabled... no
checking if zts is enabled... no
checking for re2c... re2c
checking for re2c version... invalid
configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers.
checking for gawk... no
checking for nawk... no
checking for awk... awk
checking if awk is broken... no
checking for MySQLi support... yes, shared
checking whether to enable embedded MySQLi support... no
mysql_config not found
configure: error: Please reinstall the mysql distribution

4 Ответ от Hanut 2012-03-28 11:10:35