I've built the release version of OpenSSL 1.1.1c libraries without a problem, but I cannot create the Debug version.
According the documentation I used:
perl Configure --debug VC-WIN64A
However the Perl % (ActiveState) doesn't recognize the argument debug.
When I use -d, the build alone will switch to the debug execution mode.
Somewhere on Internet I found the form:
perl Configure debug-VC-WIN64A
However, I couldn't confirm it with the documentation.
What is the proper format for the Perl?
-d does not work with windows builds... The original poster had it correct, he just had the parameters in the wrong order...
On Windows, to build a debug version, you do it like:
perl Configure VC-WIN64A --debug
I just verified it just now, as I'm building 1.1.1l as we speak. Omitting that flag, defined NDEBUG, but specifying that flag defines DEBUG. Original poster specified --debug before VC-WIN64A, but it must be specified after.
according the documentation I used:
perl Configure --debug VC-WIN64A
However the Perl % (ActiveState) doesn't recognize the argument debug.
When I use -d, the build alone will switch to the debug execution
mode.
According to Compilation and Installation on the OpenSSL wiki, you should use -d. See Configure Options
Somewhere on Internet I found
perl Configure debug-VC-WIN64A
however, I couldn't confirm it with the documentation.
Use Configure LIST to show the targets.
$ ./Configure LIST | grep VC
VC-CE
VC-WIN32
VC-WIN32-ARM
VC-WIN32-ARM-UWP
VC-WIN32-ONECORE
VC-WIN32-UWP
VC-WIN64-ARM
VC-WIN64-ARM-UWP
VC-WIN64A
VC-WIN64A-ONECORE
VC-WIN64A-UWP
VC-WIN64A-masm
VC-WIN64I
You might also be interested in NOTES.WIN, which are the build and install notes for Windows. The notes do not list --debug.
It looks like --debug is detailed in INSTALL file. --debug works on Linux for OpenSSL 1.1. Maybe it does not work on Windows, or maybe it used to work with a version like OpenSSL 1.0.
(I don't have a Windows machine with Perl, so I can't run the tests for you).
Related
I know this might be a dumb question, but I cannot figure out how to install and use Apache Daffodil. Any help would be appreciated. I cannot find anything helpful. Thank you!
Download apache Daffodil from below url
https://downloads.apache.org/daffodil/3.0.0/src/apache-daffodil-3.0.0-incubating-src.zip
The binary Daffodil releases contain a /bin directory that contains two scripts: daffodil.bat for Windows and daffodil for Linux. These files must be executed on the command line.
Extract downloaded zip
Path of bin directory export as environment variables.
After that you can verify its installed or not via below cammand it will show the version of daffodil
daffodil --version
Global Options
-d, --debug [FILE]
Enable the interactive debugger. See the Interactive Debugger documentation for more information.
The optional FILE argument contains a list of debugger commands that are provided to the debugger as they were typed by the user.
This option cannot be used with the --trace option.
-t, --trace
Enable a trace mode. This mode prints out helpful information during every stage of parsing.
This option cannot be used with the --debug option.
-v, --verbose
Enable verbose mode and increment verbosity level. Each additional v provides a new level of information.
--version
Display the version of Daffodil.
--help
Display help message.
I'm trying to use pp (the perl compiler) to create an application that can run independent of the perl installed library and interpreter.
It successfully creates a compiled executable although I had to use the -x -c options to get it to find dependencies successfully. It will run on my machine but when I try it on another machine I get this error so clearly there is still some dependency:
501 Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)
I am running it on MacOS 10.14.1 if that makes any difference. Thanks!
LWP::Protocol::https is loaded dynamically when needed, so pp has no way of knowing it's needed by default.
Solution 1
Pass -x to pp, and make sure the module is actually loaded in the run pp uses to determine the modules to include. This would probably be achieved by using LWP to make an HTTPS request during that run. --xargs=... might come in useful for this.
Solution 2
Pass -M LWP::Protocol::https to pp. You could also pass -M 'LWP::Protocol::**' to get all protocols handlers you have installed.
Solution 3
Add use LWP::Protocol::https (); to your script or an included module. Including a comment indicating why you are doing this would be appropriate.
You were building Net::SSLeay on MacOS 10.14 linking it to libssl.44.dylib which is not present on MacOS 10.12 where you try to run it.
I've found it annoying having to switch between build and test systems to find out which of the libraries are missing or incompatible and need to be packed.
I am now using the following strategy:
I use perlbrew instead of system perl.
For alien dependencies I use homebrew instead of the system libraries.
I build the packed executable using pp and run the resulting program with export DYLD_PRINT_LIBRARIES=YES being set (on the development machine)
I examine the list of loaded libraries and add all those referenced in the homebrew directory tree (/usr/local/opt/ and /usr/local/cellar/in my case) using pp -l /full/path/name -l ...
I rebuild the executable.
I still check on a target machine before deploying, but chances are very high now that it just works.
I've been trying to install LuaJIT on Windows 10 for some time following the official guide, and I actually get to install it. For example, if I execute luajit I get into the prompt. Also, luajit -v returns the version of luajit (2.0.4). And I can also execute code with luajit -e <lua code>. However, whenever I try to save bytecode with luajit -b, I get the following message:
luajit: unknown luaJIT command or jit.* modules not installed
I tried to make all sort of installations: using Cygwin, luajit-rocks, MinGW, ... However, no matter what I try, I always get the same result, and I have no clue of what to do.
Could you point me to some potential problems I might be overlooking?
I have on my system Lua 5.1 and Luarocks.
Some extra LuaJIT features are implemented as separate Lua modules (e.g. jit.bcsave for bytecode saving), and LuaJIT depends on package.path to find those modules. The suggested install location for those modules is in the default package.path, but if you override it via the LUA_PATH environment variable, you have to make sure to include that location there. One easy way to do that is to put two consecutive semicolons into LUA_PATH: Double semicolons are replaced by the compile-time default value of package.path.
You need place modules to "jit" folder near with juajit.exe. That folder include some system modules (bcsave too). package.path can dont work, becouse it hardlinked, how i understand. That folders distributed with source code.
Download lua from official sice: https://luajit.org/download.html
You can see "jit" folder inside archive:
LuaJIT-2.0.5.zip\LuaJIT-2.0.5\src\jit\
I'm trying to get biotools working on my Mac so that I can run some Perl5 code that uses Bio::DB::Sam, but am stymied.
Mac OS X 10.10.4
perl 5.18.2
upgraded CPAN as per INSTALL instructions
'brew install expat' tells me that expat-2.1.0_1 is already installed
'sudo perl -MCPAN -e shell'
'install CJFIELDS/BioPerl-1.6.924.tar.gz'
'Do you want to run the Bio::DB::GFF or Bio::DB::SeqFeature::Store live database tests?' => 'n'
Install all
'Do you want to run tests that require connection to servers across the internet' => 'n'
Eventually get (with some lines deleted):
Running Build test
t/Align/AlignStats.t ................... ok
t/Align/AlignUtil.t .................... ok
t/Align/Graphics.t ..................... skipped: The optional module GD (or dependencies thereof) was not installed
...
t/AlignIO/msf.t ........................ ok
t/AlignIO/nexml.t ...................... skipped: The optional module Bio::Phylo (or dependencies thereof) was not installed
t/AlignIO/nexus.t ...................... ok
...
t/Assembly/ContigSpectrum.t ............ ok
t/Assembly/IO/bowtie.t ................. skipped: The optional module Bio::DB::Sam (or dependencies thereof) was not installed
t/Assembly/IO/sam.t .................... skipped: The optional module Bio::DB::Sam (or dependencies thereof) was not installed
t/Assembly/core.t ...................... ok
t/Cluster/UniGene.t .................... ok
Afterwards, I test with:
perl -e "use Bio::DB::Sam;"
and get:
Can't locate Bio/DB/Sam.pm in #INC (you may need to install the Bio::DB::Sam module) (#INC contains: /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2/darwin-thread-multi-2level /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
I get the same results when cloning bioperl-live from GitHub (sync'd to revision 73c446c69a77) and trying to install that way.
Note that I have installed samtools 0.1.18 (to match the version on our cluster) by:
downloading the .tar.gz
running 'make'
copying 'samtools', 'bcftools/bcftools', and 'misc/*.pl' to ~/debarcer-packages/bin, which is on my path
Afterward, I get this:
$ which samtools
/Users/gvwilson/debarcer-packages/bin/samtools
This build did not produce a '.so' file, even though there is a rule in the samtools-0.1.18 Makefile that looks like it (maybe?) ought to produce one.
The module Bio::DB::Sam provides bindings to an older version of samtools that did not rely htslib. This is an important point because you may run into issues using SAM/BAM files generated with samtools or other aligners because most tools use htslib these days.
For building the module, you are on the right track with the version you are using but it is difficult to build if you do not know the correct flags. I previously provided a solution to do this and I'll show a better way here (just use a package manager for the Perl module).
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
export SAMTOOLS=`pwd`
The last command will allow you to install the Perl module without looking for the PATH to samtools and being prompted for it. Note, the extra CFLAGS argument may not be needed on your Mac, so try without it first. It is required on Linux, and since the module uses so much memory you will likely only be using this on a Linux machine. Now, install the Perl module.
cpanm Bio::DB::Sam
or cpan if you prefer. That should get you a working Bio::DB::Sam. I don't know what you are trying to do but I will mention that the fine folks over at EBI have developed bindings to htslib called Bio::DB::HTS based on Lincoln Stein's XS code in the Bio::DB::Sam module. This is really what you should be using because the version of SAMtools mentioned above is really old and not being developed. That is my opinion and a word of caution though, nothing wrong with Bio::DB::Sam.
edit:
You find it easier to manage Perl without using the "system" Perl, and here is one solution. Other people may have their preferred method, but perlbrew (combined with cpanminus) will make this type of work fun and much less of a pain (and they are popular choices). That would be my first step: set up perlbrew, install Perl 5.22, then install cpanminus. That might sound challenging but it is just a few commands. Something along the lines of:
curl -L http://install.perlbrew.pl | bash
source ~/perl5/perlbrew/etc/bashrc
perlbrew install perl-5.22.1
perlbrew switch perl-5.22.1
perlbrew install-cpanm
should do the trick. That will give you a kick-ass Perl with some nice features not available with your "system" Perl. This is a good idea because using /usr/bin/perl requires sudo, it involves messing with the system libraries which might cause an issue, and the recent Apple changes mean that working with root directories/libraries is completely unstable.
You need to install an additional (optional) module to use samtools. That's what the The optional module Bio::DB::Sam message is about. You don't need it for the rest of BioPerl, so it's not a hard dependency.
For Bio::DB::Sam, you need samtools-0.1.17 (the latest version the module works with according to its docs). I downloaded the source and ran make. There were some warnings, but it appears to work. From your question, I don't think you had a problem here.
I then installed Bio::DB::Sam:
$ cpan Bio::DB::Sam
There were some compiler warnings, but the module passed its tests and installed. The cpan command took care of dependencies too, so it also installed BioPerl for me.
If you need some environment variables, you can set them for a one-off run of the command:
$ CFLAGS=... SAMTOOLS=... cpan Bio::DB::Sam
Note that installing Bio::DB::Sam prompted me for the location of samtools. I pointed it at the build directory:
$ cpan5.22.0 Bio::DB::Sam
Running install for module 'Bio::DB::Sam'
Configuring L/LD/LDS/Bio-SamTools-1.43.tar.gz with Build.PL
This module requires samtools 0.1.10 or higher (samtools.sourceforge.net).
Please enter the location of the bam.h and compiled libbam.a files: /Users/brian/Downloads/samtools-0.1.17
I'm betting there's not something complicated like the answer SES gave. You just need an optional module. The README for Bio::DB::Sam notes some problems that people might have and offers so workarounds, but I didn't run into these problems and my setup is close to yours.
Note that Alien::SamTools is a Perl package that installs the non-Perl samtools, but it says it installs 0.1.19. Maybe that works too, but that's not what Bio::DB::Sam says on the tin.
This is sort of a followup to this thread--unfortunately I didn't make any progress at the time so I thought I would start over. I am consistently getting this in the debugging log (QtCreator 2.3.1, Qt 4.7.3, gdb 7.2):
A syntax error in expression, near 0'.\n"
295^error,msg="A syntax error in expression, near0'."
&"Python scripting is not supported in this copy of GDB.\n"
296^error,msg="Python scripting is not supported in this copy of GDB."
&"Python scripting is not supported in this copy of GDB.\n"
297^error,msg="Python scripting is not supported in this copy of GDB."
&"Python scripting is not supported in this copy of GDB.\n"
298^error,msg="Python scripting is not supported in this copy of GDB."
&"Undefined command: \"bbsetup\". Try \"help\".\n"
299^error,msg="Undefined command: \"bbsetup\". Try \"help\"."
dThe debugging helper library was not found at .
&"source /home/matt/QtSDK-4.7.3/pythongdb/gdb\n"
&"/home/matt/QtSDK-4.7.3/pythongdb/gdb:1: Error in sourced command file:\n"
&"Undefined command: \"\". Try \"help\".\n"
300^error,msg="/home/matt/QtSDK-4.7.3/pythongdb/gdb:1: Error in sourced command file:\nUndefined command: \"\". Try \"help\"."
&"Undefined command: \"bbsetup\". Try \"help\".\n"
301^error,msg="Undefined command: \"bbsetup\". Try \"help\"."
dThe debugging helper library was not found at .
302^done
<303set substitute-path /var/tmp/qt-src /usr/include
The specific problem is that without the debugging helper, I'm unable to see the contents of QStrings and many other data structures during the debugging process, which makes it much more time-consuming. The error messages above are symptomatic, the problem arises when gdb can't find the debugging helper.
Anyway, looking at the discussion referenced in the answer in the above thread, I hunted around for different versions of gdb on my system but each one of them produced the same error (with the path changed appropriately of course), including version 7.3.1 when I downloaded it. I've also located libDebuggingHelper.so, but sticking it in different places hasn't helped either. Lastly looking at ./configure --help for gdb, I didn't see any options for enabling/disabling python in the build. Anybody know how I can get this to work?
This site claims you need to configure GDB using
./configure --with-python
It's pretty clear from the error message that the GDB you built does not have python support compiled in.
In gdb/config.log look for messages like checking whether to use python and see why GDB decided to not use Python on your system.
Perhaps you need to install Python development packages?
Once you've configured GDB to use Python, an easy way to check whether Python support is properly compiled in is:
(gdb) python print "hello"
If that prints anything other than hello, you are still not where you want to be.
I solved the problem with
sudo apt-get install gdb-multiarch
Thanks to #Employed-Russian for allowing me to check if GDB indeed has python support.
I did have to use the syntax
(gdb) python print("Hello")
To get a proper response from python within GDB.