To add the php apache2 module in Yocto I created a file recipes-devtools/php/php_%.bbappend with the following content:
PACKAGECONFIG = " mysql sqlite3 imap opcache openssl ${#bb.utils.filter('DISTRO_FEATURES', 'ipv6 pam', d)} apache2"
LIBS_pn-php =" -lpthread "
export LIBS
THREADS_pn-php = "pthread"
export THREADS
The module is built, but the file tmp-glibc/sysroots-components/cortexa7hf-neon-vfpv4/php/usr/lib/apache2/modules/libphp7.so is not copied to the rootfs (/usr/lib/apache2/modules/).
Why it does not deploy the file?
As temporary workaround (and to learn how to handle Yocto's path) I'm trying to manually deploy it with a ROOTFS_POSTPROCESS_COMMAND. To avoid absolute paths, what variable should I use to find out the file above under the tmp-glibc output dir? Something like:
${TMPDIR}/sysroots-components/cortexa7hf-neon-vfpv4/php/usr/lib/apache2/modules/libphp7.so
or there's something better?
In Yocto, files (which are installed in ${D} either manually in do_install or by the make, cmake, autotools, etc... in e.g. do_compile) are put in a package when they match one of the regular expression (or glob, not entirely sure about that) contained in FILES_foo.
One recipe can (and usually does) provide multiple packages. So you'd have multiple FILES_foo1 with their own paths to match.
In Yocto, the file is put in the first package where one of the paths in its FILE_foo matches the file. Even if the file matches the paths of other packages, it'll ever be in only one package, the first one.
FWIW, packages are created from leftmost to rightmost in PACKAGES variable in the recipe. By default, the PACKAGES variable is ${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n292).
The default FILES_* variables are defined in bitbake.conf as well, c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf. Look for everything starting with FILES_.
In there, you can see that by default, FILES_${PN} has ${libdir}/lib*${SOLIBS} (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n296) packaged. SOLIBS is, by default, .so.* (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n280), which means only dot versions of libraries are packaged in the ${PN} package (if they are not matched by another package before).
FILES_${PN}-dev on the other hand packages ${FILES_SOLIBSDEV} which defaults to ${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}, with SOLIBSDEV in turns defaults to .so (c.f. http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n313, http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n314 and http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n283).
Please note that library filenames should all start with lib to be able to be matched by the default FILES_*.
TL;DR: By default, lib*.so.* in FILES_${PN} and lib*.so in FILES_${PN}-dev.
For your specific issue, you can see that ${libdir}/apache2 directory is packaged in php-modphp thanks to FILES_${PN}-modphp (c.f. http://git.openembedded.org/meta-openembedded/tree/meta-oe/recipes-devtools/php/php.inc#n243).
So you need to add php-modphp (assuming ${PN} resolves to php) to your image to be able for the lib to be installed in your rootfs.
Related
We facing a problem where we need to configure a path in one of our config-file.yml. It's a path to an CLI-Script. We facing an old known problem "directory separators" for UNIX/Windows - / - \ . Now we want to configure just one path for both OSs.
Currently we need to switch the path manually depending on the currently used OS. This breaks our VCS handling / application stability all the time.
Unix
bin_path: path/to/script
Windows
bin_path: path\to\script
Is there something like a placeholder known from PHP superglobal DIRECTORY_SEPARATOR? We focusing a solution where we not need to replace the separators in our scripts. I stuck in this problem for a couple of times when using yaml files.
YAML is a data description language and as such has no support for data flowing into the YAML document from the outside (i.e. variables you can use in the document). The only thing you can theoretically do is to structure your YAML document in a way that lets you select the value you actually want afterwards. Example:
bin_path:
unix: path/to/script
windows: path\to\script
Then, when loading the file, you can select the appropriate path for the current operating system. However, this seems convoluted compared to the approach where you simply replace / with \ when on Windows.
An other solution is to just use one path configured for Windows or UNIX like in the following example. In this way you don't need to configure a specific path for each operation system.
bin_path: path/to/script
In e.g. PHP you could normalize your pass inside your application by using realpath.
realpath('path/to/script'); //creates an absolute path including OS based directory separators
Are functions of an extension fetch-able for an IDE like PHPStorm when they are given path to php.ini file of extension folder path? I saw that EasyPHP list functions of an extension beside it for those extension that are delivered with it, but it do not display any function for Yaf and Phalcon that is manually installed.
For Phalcon -- get yourself Phalcon Developer Tools ( http://phalconphp.com/download ) -- it contains stub files that can be used by IDE for code completion: https://github.com/phalcon/phalcon-devtools/tree/master/ide/phpstorm
For Yaf -- similar approach (stub file for usage inside IDE): https://github.com/suin/phpstorm-yaf-doc
As this frameworks are php extensions, just make sure, you have configured you php include path in IDE right.
config -> PHP -> and add there something like /usr/share/php (your location)
I use the stubs provided on packagist and install them with composer. https://packagist.org/packages/sneakybobito/phalcon-stubs
composer.json
{
"require": {
"sneakybobito/phalcon-stubs": "1.2.3"
}
}
For compiled extensions you will need a stub file which contains the name of the functions. Since recent versions of PHP include reflection capabilities for extensions[you can get the extension defined classes and functions and then reflect them to get their parameters] they should be possible to generate them.
I'm giving https://github.com/schmittjoh/php-stubs a try but the PHP svn server is down at the moment so it won't run... Will try to check back here later and update on if it works.
Should ZF and PHP have the same path to include in php.ini, or can they be put in separate directories? This is the include path in my php.ini:
;Windows: "\path1;\path2"
include_path = ".;C:\xampp\php\PEAR;C:\ZF\library\"
I couldn't find any Zend documents that specify which, copying ZF\library to xampp\php\PEAR or the entire ZF directory, or using multiple include paths, is recommended for MVC app production. Is there a good practice or does it depend more on not having access to a certain part of a server or if you are using shared hosting, combining PHP and ZF would be the better option?
Should ZF and PHP have the same path to include in php.ini, or can
they be put in separate directories?
It is fine to have multiple directories listed in your php.ini.
include_path = ".;C:\xampp\php\PEAR;C:\ZF\library\"
The following would be better:
include_path = "C:\xampp\php\PEAR;C:\ZF\library\"
In other words, you don't need the "." in your path since anything that needs to be included in the current working directory can be included like this "./path/to/file.php".
Furthermore, you will want to use an autoloader but having the autoloader search ".", is more work than is needed.
Finally, I generally have an include path of:
include_path = "C:\xampp\php\PEAR"
The reason is that since PHPUnit is generally installed via the PEAR installer, I always want that globally available; however, for everything else, I can wait until I have access to a PSR-0 compliant autoloader.
Hope that helps.
I have Aspell successfully installed and have compiled PHP with Pspell, and everything seems to be working fine.
The only thing I am unable to do, is create a list of "ignore" words, or a personal dictionary, however you want to refer to it.
I've tried the steps outlined here and here but neither had any effect.
As described at the above link and on the Aspell documentation, I tried creating a personal dictionary as outlined in the manual:
personal_ws-1.1 en 0
Rubiflex
quasirhombicosidodecahedron
I placed this in the aspell directory, my home directory, the root directory, and it was never picked up. The Aspell documentation never actually says where it should live or how to otherwise load it.
The other reference is to creating an individual word list:
Create a txt file with the words that you'd like to add to the dictionary, where each word is on a separate line then run the following command:
aspell --lang=en create master ./custom.rws < test.txt
This will create a file called custom.rws that will contain the aspell encoded word(s) for the dictionary. You can name the file
anything you want as long as the extension is .rws. Now to add this
to the dictionary move the custom.rws file to the dictionary location
which is /usr/lib/aspell by running the following command:
cp custom.rws /usr/lib/aspell/
To finish adding it to the dictionary change into the dictionary directory by running the following:
cd /usr/lib/aspell/
then edit the following file: nano en_US.multi
and add the following line:
add custom.rws
Neither of these methods seemed to work and I cannot find any clear examples of how to properly add a dictionary or word list. These were the two most promising methods I was able to find and neither worked. Does anyone know how I can get Aspell to use a personal dictionary file I create?
Thank you for your time.
EDIT:
The steps outlined here worked for me. The are much like the ones outlined here except that the latter refers to "en_US.multi" where the former refers to "en.multi". After adding the custom list to en.multi (as opposed to en_US.multi), it was working as expected.
For my latest work onto the Perl's Text::Aspell module and code to determine the mother language of a Web visitor querying a company's search engine, I came across some of the pitfalls you describe (personal dictionary not implemented in Aspell6). However I worked it around using the 'extra-dicts' notion, one for each possible language.
I also had to workaround the fact that Aspell owns no dictionary for the Arabic, Hebrew, Japanese, Chinese and Korean languages. These languages are dealt with specifically.
You may view the full latest Perl's and bash codes for Linux and Windows running Windows/MinGW at http://vouters.dyndns.org/tima/Linux-Windows-Perl-Aspell-Determining_the_country_of_a_Web_query.html. You may use the URL links in the REFERENCES section of the document to adjust some of the Perl's code notions to PHP.
I was able to add a personal dictonary using option --add-extra-dicts to aspell call
aspell -c --add-extra-dicts=./custom.rws my_text_to_spell_check.txt
custom.rws has been created as depicted by OP:
aspell --encoding=UTF-8 --lang=<lang> create master ./custom.rws < test.txt
And remember to add --encoding opton to match the correct encoding for your source file.
I Hope this can help someone!
Using the aspell version below with Cygwin:
International Ispell Version 3.1.20 (but really Aspell 0.60.6.1)
it was looking for a personal dictionary named .aspell.en.pws in my home directory, regardless of what I specified on the command line with the --personal option. I was able to place a symbolic link named .aspell.en.pws in my home directory and let it point to a different location on my file system. I had to create the file first and add the required header before aspell would start adding to my personal dictionary.
In short, you can do this:
echo "personal_ws-1.1 en" > ~/my/file/location.pws
ln -s ~/my/file/location.pws ~/.aspell.en.pws
We have an issue using the PEAR libraries on Windows from PHP.
Pear contains many classes, we are making use of a fair few, one of which is the Mail class found in Mail.php. We use PEAR on the path, rather than providing the full explicit path to individual PEAR files:
require_once('Mail.php');
Rather than:
require_once('/path/to/pear/Mail.php');
This causes issues in the administration module of the site, where there is a mail.php file (used to send mails to users). If we are in an administrative screen that sends an email (such as the user administration screen that can generate and email new random passwords to users when they are approved from the moderation queue) and we attempt to include Mail.php we "accidentally" include mail.php.
Without changing to prepend the full path to the PEAR install explicitly requiring the PEAR modules (non-standard, typically you install PEAR to your path...) is there a way to enforce PHP on Windows to require files case-sensitively?
We are adding the PEAR path to the include path ourselves, so have control over the path order. We also recognize that we should avoid using filenames that clash with PEAR names regardless of case, and in the future will do so. This page however (which is not an include file, but a controller), has been in the repository for some years, and plugins specifically generate URLS to provide links/redirects to this page in their processing.
(We support Apache, Microsoft IIS, LightHTTPD and Zeus, using PHP 4.3 or later (including PHP5))
As it's an OS level thing, I don't believe there's an easy way of doing this.
You could try changing your include from include('Mail.php'); to include('./Mail.php');, but I'm not certain if that'll work on a Windows box (not having one with PHP to test on).
having 2 files with the same name in the include path is not a good idea, rename your files so the files that you wrote have different names from third party libraries. anyway for your current situation I think by changing the order of paths in your include path, you can fix this.
PHP searches for the files in the include paths, one by one. when the required file is found in the include path, PHP will stop searching for the file. so in the administration section of your application, if you want to include the PEAR Mail file, instead of the mail.php that you wrote, change your include path so the PEAR path is before the current directory.
do something like this:
<?php
$path_to_pear = '/usr/share/php/pear';
set_include_path( $path_to_pear . PATH_SEPARATOR . get_include_path() );
?>
If you are using PHP 4, you can take advantage of this bug. Off course that is a messy solution...
Or you could just rename your mail.php file to something else...
I'm fairly certain this problem is caused by the NTFS code in the Win32 subsystem. If you use an Ext2 Installable File System (IFS), you should get case sensitivity on that drive.