On VirtualBox VM OpenBSD:
I was trying to build apr 1.5.1 in my attempt to build an apache 2.4 server WITHOUT packages( ie. from source ) and when I ran make test, testlock failed with:
testlock : -Line 300: Timer returned too late FAILED 1 of 4
...
*** Error 1 in test (Makefile:186 'check')
*** Error 1 in /a/b/c/d/e/f (Makefile:127 'check')
I have no idea what to do with it. What is the course of action for something like this?
You may want to try using a slightly older version of apr; perhaps one from an OpenBSD packages site (somewhere like this OpenBSD Packages site?)
Note: any downloads and installations that you choose to make from sites like these are your decision. Please make sure to read related documentation for compatibility information, too, before making a decision about installing software in your environment!
Also, your version of OpenBSD may make a difference for what package site would be best to use... the OpenBSD packages site above is just an example of what these sites may look like.
For future reference, you can find more information about these sort of packages in the OpenBSD packages and ports documentation.
Related
I am trying to build Nmap from source code, and I think I am incorrectly installing/compiling/using OpenSSL, but I'm not sure it is the first time using many of the tools found in the instructions for nmap compilation.
I follow the instructions here: https://nmap.org/book/inst-windows.html#inst-win-source
I follow everything, including the instructions found at https://svn.nmap.org/nmap-mswin32-aux/OpenSSL-upgrade.txt; which is required since the OpenSSL folder that comes with the nmap source distribution does not include some header files from configuring OpenSSL.
I can build every project within the solution up until nsock, in total I get about 3700 errors. For nsock its 435 errors, things like:
"sslctx is not a member of npool"
"ssl_session is not a member of niod"
but also things like "syntex error: missing ; before *"
My directory looks like nmap -> [nmap-7.93, nmap-mswin32-aux]
Pretty sure it has something to do with how I'm installing or building or using OpenSSL, but I follow the instructions https://svn.nmap.org/nmap-mswin32-aux/OpenSSL-upgrade.txt closely and multiple times now.
I'm using MSVC 2022, I have 2019 installed (I'm really not sure which to use, or how to stop perl from using 2022 and use 2019 tools), or if I'm missing something else that is basic.
I did notice perl uses nmake from MSVC2022, and it's mentioned on the nmap site to use 2019. Could this be the problem? How would I get pearl to use MSVC2019 to test it out?
I followed the instructions multiple times, with both openssl sources 1.1.1s and 3.0.7 in MS VS 2019 and 2022. The result is all up 3700 errors about syntax errors and being unable to identify ssl names.
Happy to provide any additional info like perl dump files if anyone can aid me, or the complete list of errors. Any help would be greatly appreciated.
I trying to get set up with Variant Effect Predictor (VEP) on the command line. I'm following the setup tutorial but I'm encountering some errors around dependencies. I'm also quite new to the command line so if anyone is able to break down the solution too then I'd be very grateful. Thanks!
Tutorial: https://www.ensembl.org/info/docs/tools/vep/script/vep_tutorial.html
VEP requirements: http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
I also have Perl v5.32.1.
What I've done:
I installed dependencies (listed in the requirements page) with the following commands:
- sudo -s cpanm DBI
- sudo -s cpanm Archive::Zip
- sudo -s cpanm DBD::mysql
For DBD:mysql, I got the follwoing message:
--> Working on DBD::mysql
Fetching http://www.cpan.org/authors/id/D/DV/DVEEDEN/DBD-mysql-4.050.tar.gz ... OK
Configuring DBD-mysql-4.050 ... N/A
! Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
Trying it out anyway, I ran perl INSTALL.pl (from the tutorial page) and got the message below. I would like VEP to run in online mode too if possible.
`WARNING: DBD::mysql module not found. VEP can only run in offline (--offline) mode without DBD::mysql installed
http://www.ensembl.org/info/docs/tools/vep/script/vep_download.html#requirements
Hello! This installer is configured to install v104 of the Ensembl API for use by the VEP.
It will not affect any existing installations of the Ensembl API that you may have.
It will also download and install cache files from Ensembl's FTP server.
Checking for installed versions of the Ensembl API...done
Setting up directories
Destination directory ./Bio already exists.
Do you want to overwrite it (if updating VEP this is probably OK) (y/n)? y
- fetching BioPerl
- unpacking ./Bio/tmp/release-1-6-924.zip
ERROR: Unable to unpack file ./Bio/tmp/release-1-6-924.zip without Archive::Extract or tar/unzip/gzip`
You show us this error:
Configure failed for DBD-mysql-4.050. See /root/.cpanm/work/1626111140.5937/build.log for details.
So looking in there will give you more clues about what the problems are. Without that, we can only guess.
But we can make educated guesses. The DBD::mysql distribution comes with a file called DBD::mysql::INSTALL which will talk you through some of the problems you'll find while installing this module.
It's important to note that DBD::mysql is a wrapper around MySQL's client libraries. They are written in C, so you'll need a C compiler installed in order to build DBD::mysql. You'll also need the client libraries and the development versions of the client libraries (for the C header files that you'll need to compile the module). On Ubuntu, those packages are called "libmysqlclient" and "libmysqlclient-dev". If you don't have a C compiler, then you'll want to install "gcc" too.
But this is all getting a bit complicated. There's another, simpler, approach. If you're using the system version of Perl (the version that was installed as part of the operating system and probably lives in /usr/bin/perl) then I'd recommend using the pre-build Ubuntu version of the package, which you can install by running:
$ sudo apt-get install libdbd-mysql-perl
Installing that version uses the OS's own package manager, and the package manager knows which other packages are needed in order for it to work - so it will install those as well.
People will probably complain that you're better off installing the modules from CPAN as it gives you more flexibility and allows you to use more up-to-date packages than the versions from your OS repos. And they're right. But, honestly, if you're a non-Perl programmer who just wants to get an application up and running, this is by far the simplest approach.
(But, as I said above, this is all guesswork as you haven't shared the most important errors with us.)
Last week I installed PHP 7.0.0RC2 on my Raspberry Pi B.
I am able to view PHP pages, however, the problem is that I cannot connect to the database using mysqli (I know that mysql is no longer supported in PHP v7).
I ran the ./configure command with --with-mysqli=shared.
However, when I check which modules are installed using the php -m command, I do not see mysqli.
I tried adding extension=mysqli.so to the php.ini file.
It first complained that the mysqli.so file could not be found, so I tried copying the mysqli.so of my php5 version to the extensions folder.
However, this did not solve the problem and resulted in the following error message:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/no-debug-non-zts-20141001/mysqli.so' - /usr/local/lib/php/extensions/no-debug-non-zts-20141001/mysqli.so: undefined symbol: zval_used_for_init in Unknown on line 0
Does anyone got any suggestions of how to get mysqli to work with my PHP7 installation on my Raspberry Pi?
You may find detailed information in the configure output, but it's pretty hard to catch, and if it's not a fatal error, won't stop the build going ahead when you make.
The recommended (read: only decent) driver for MySQLi is the MySQL Native Driver (mysqlnd).
If you want MySQLi to be built shared, you must also build mysqlnd shared, and everything that depends on it (PDO MySQL, for example).
It's going to be simpler to just build the native drivers static, using the configure option:
--with-mysqli=mysqlnd
Which will enable a static build of mysqlnd and mysqli.
If for some reason you really do want to build shared, then you'll need configure options that closely resemble, if not are exactly the same as:
--enable-mysqlnd=shared
--with-mysqli=shared,mysqlnd
Which will result in a shared build of mysqlnd and mysqli, requiring you to add extension=mysqlnd.so and extension=mysqli.so in the appropriate order (the latter depends on the former), in the appropriate place.
Remember to make distclean before you re-configure the build, surprising things will happen if you do not ;)
I installed the eggPlant15.20.rpm on our Linux/RedHat7 system, however seem not to take its license properly, causing it not launch at all.
I was wondering if the eggPlant RedHat installation is not sufficient, and whether we need other dependencies.
When running efls command to launch the License Panel, I see the below library messages:
[root#RHEL-BLD1 Library]# efls
/usr/GNUstep/System/Tools/gpbs: /usr/GNUstep/System/Library/Libraries/libjpeg.so.62: no version information available (required by /usr/GNUstep/System/Library/Libraries/libgnustep-gui.so.0.23)
/usr/GNUstep/System/Tools/gpbs: /usr/GNUstep/System/Library/Libraries/libjpeg.so.62: no version information available (required by /lib/libtiff.so.3)
[root#RHEL-BLD1 Library]#
Googling the above libraries does not provide much help.
Anybody knows the cause of the above problems?
I have installed Net-SMTP-SSL (/usr/bin/perl install-module.pl Net::SMTP::SSL) since I'd like to configure Bugzilla email with Gmail. I did't got any error. However, when I run './checksetup.pl --check-modules', I still get the result:
Checking for Net-SMTP-SSL (v1.01) not found
I also try to re-install it and I still get the same output. Here is my system information:
Ubuntu 12.04
Bugzilla 4.4.6
After having the same problem with Bugzilla recently, I ran across this rejected bug report:
https://bugzilla.mozilla.org/show_bug.cgi?id=897355
It mentions that there are some dependencies that Bugzilla isn't installing, but doesn't say which ones. So I just ran cpan and issued the upgrade command from the cpan console to upgrade all packages. This went though and installed a few dependencies from various packages that it said were missing. I didn't see which ones were related to the SMTP SSL package since it was installing stuff several levels deep in dependencies, but after running that and then running checksetup.pl in Bugzilla, the problem seemed to be fixed. Warning: It did take quite a while to upgrade all packages, though.
That fixes the issue with Bugzilla not detecting properly, but unfortunately it seems there's a bug in Net::SMTP::SSL conflicting with one of it's own dependencies. You'll get an error something like "Not a GLOB reference" if you try to run the package directly. You can see it by running this after updating all of the packages:
perl -MNet::SMTP::SSL -wE 'say $Net::SMTP::SSL::VERSION'
If you get a version number returned then it's working, but I get an error and have seen other posts about it, too. I haven't been able to fix this problem yet, but there's probably some combination of the SSL package and various versions of it's dependencies that actually works, just not the latest of each. Otherwise, I would think there would be a known issue in Bugzilla release notes as they would have run across it during testing.
I haven't had time to do it and haven't seen that anyone else has either including the package maintainer, but I suppose you could find all of the dependencies for Net::SMTP:SSL and then one by one update the packages using something like:
cpan upgrade Net::SMTP::SSL
Then replace Net::SMTP::SSL with each of it's dependencies one at a time and test using the perl command above. When it breaks, you'll know which package is conflicting. You can then roll that package back to an earlier version and update all other dependencies and hopefully it will fix the issue. It's definitely possible that no combination will work, though, and if that's the case, I'll be a little disappointed in Bugzilla's testing process.
You can find dependencies using various methods, but CPAN has one. Here's a link to an article about how to create a perl script to use it: https://metacpan.org/pod/CPAN::FindDependencies
Anyway, this may not solve your problem, but I hope it helps in tracking down the issue, and know that you are not alone. If you do find out anything, please post it here. I will do the same if I have more time to work on it later.