I've got a very simple program which lists all .txt files in a given directory. This program has run perfectly on my Mac which has the Rakudo Star version 2019.03.1
use File::Find;
my $folder="../Documents";
.say for find dir => $folder, name => /'.txt' $/;
When I've tried to run the same program on Windows 7 which had Raku 2020.12.1 it gave this:
$ raku html-adder.rk
===SORRY!=== Error while compiling C:\Users\lars\raku/html-adder.rk
Could not find File::Find in:
inst#C:\Users\lars\.raku
inst#C:\Programs\rakudo-moar-2021.02.1\share\perl6\site
inst#C:\Programs\rakudo-moar-2021.02.1\share\perl6\vendor
inst#C:\Programs\rakudo-moar-2021.02.1\share\perl6\core
ap#
nqp#
perl5#
at C:\Users\lars\raku/html-adder.rk:12
I've updated the Raku to version Raku 2021.02.1 and the same error again. I've installed it by unzipping the rakudo-moar-2021.02.1-01-win-x86_64-msvc.zip i.e. without using any installer. And as regards to the Raku on Mac, I don't remember installing the File::Find module, nor do I know how to list the installed modules, i.e. I haven't checked if File::Find was installed on Mac or Windows 7.
How to make this program work on Windows 7?
File::Find is not built into Raku or distributed with Rakudo Star; to my knowledge, it never has been.
It is a module in the ecosystem that you can install with Zef (use the command zef install File::Find).
It is also a very short library. If you are interested in fixing your script without adding a dependency, you may want to check out the source code for File::Find; it is short enough that you could easily implement the same functionality yourself.
Related
I'm trying to run a piece of software I built in MSYS2 MINGW32 shell. The software is 32bits (don't have time to port it to 64bits) and there is one statically linked executable. Here is how I setup the build environment:
Installed a fresh copy of MSYS2;
$ pacman -Syu
Installed the following packages: git mingw-w64-i686-gcc mingw-w64-i686-cmake mingw-w64-i686-SDL mingw-w64-i686-SDL_mixer mingw-w64-i686-zlib mingw-w64-i686-libpng mingw-w64-i686-make
Git checkout the repo
Run the build in CMake
Build runs fine and the exe is generated.
Now the problem starts: the executable can't run and displays an error message about missing DLLs. I copied the missing DLLs to the same folder of the executable, and them another error message pops up complaining about error 0xC000007B, which I tracked down to be missing dependencies. After a while I figured out that the problem was that some of the DLLs is missing a dependency itself. Copied this last dependency to the folder.
Now, the big question: I can run the exe perfectly fine in the MINGW32 shell but I can't run it neither in cmd.exe nor by double-clicking in Windows Explorer and this is a problem (I can't ship a software this way). Is there any way to produce a binary that is able to run from explorer and from cmd.exe? What is the cause of this problem? Can it be mitigated?
I solved my problem!
After a lot of research, I realized that nothing was wrong with my MSYS2 build/setup/dependencies. The real problem was that CMake hide one parameter for the linker: -mwindows. Actually, the CMake find_package routine from one of the libraries I'm using (SDL) added this parameter to the linker command line parameters.
Adding a -mconsole to the linker parameters (using add_link_options("-mconsole")) solved the problem. The CLI now works as expected.
Thank you all for your help.
I want to investigate a new application for JPEG 2000 encoding and decoding. I downloaded openjpeg-master and managed to cobble together the ability to cmake the files. After a bunch of grinding, this resulted in the following output:
"Build files have been written to: C: openjpeg-master/build
\build> "
Any "normal" Unix installations have a multi-step installation like this:
"UNIX/LINUX - MacOS (terminal) - WINDOWS (cygwin, MinGW)
To build the library, type from source tree directory:
mkdir build
cd build
cmake .. -DCMAKE_BUILD_TYPE=Release
make
Binaries are then located in the 'bin' directory.
To install the library, type with root privileges:
make install
make clean
To build the html documentation, you need doxygen to be installed on your system. It will create an "html" directory in TOP_LEVEL/build/doc)
make doc"
But the Windows 10 equivalent is unclear, to put the most charitable spin on it. You can find it here: "https://github.com/uclouvain/openjpeg/blob/master/INSTALL.md"
Some questions arise:
is there a better starting place for installing JPEG 2000 that actually shows me how to install it and run the tests?
if not, how do I get from the build files to installing the libraries and making the test programs?
Is there more information I can dig out that would help to answer these questions?
Since I'm allergic to Visual Studio, I overlooked a nice tutorial specifying how to install something as complex as openjpeg by direct clone from github. However, in desperation, I found it and it worked. It is Visual Studio Community 2019 Version 16.8.3. I needed only to use -DTHIRDPARTY to get the third party libraries installed. There is a drop-down menu to build and install OPENJPEG. All I need to do now is figure out how to compile and run the utilities that invoke the installed libraries ...
actually, the complete line to add was -DBUILD_THIRDPARTY:bool=true.
Somewhere in my frantic random search for a way forward, I remember seeing the thought that to make the tests work, I merely need to find files like *.vsproj and run them a separate VS solutions. Some random guesswwork with .vdproj files in src/bin/... hasn't produced anything good. Is there not a document somewhere showing how to run the tests?
Is there any command in the Perl6 Rakudo distribution which lists all the installed modules on the system?
I tried the following command:
p6doc NativeCall
and get the following error :
===SORRY!===
Cannot invoke this object (REPR: Uninstantiable)
but when I write a p6 file which contains :
use NativeCall;
it compiles with no problem.
How can I browse for such a Perl 6 module (like perldoc for Perl 5) and how can I list all the installed Perl 6 modules?
The module manager is zef, not p6doc
p6doc ... is meant for managing (searching/displaying) documentation not for managing modules.
zef should already be installed on your system. If not, install it from its github repo.
The error message you got from p6doc suggests something is borked in your installation. I think it's most likely something not worth chasing for another month so I suggest you ignore it for a month, make sure you're running an up-to-date Perl 6 distribution (eg the latest Rakudo Star), and then, if it's still around, consider speaking up about it on #perl6 and mentioning this closed bug report.
Hth.
zef is your (best) friend in Perl6 universe.
zef --help
will give you any information you have ever wish aboutZef and how to use it and therefore any information about any installed modules.
zef list --installed
If you are looking for a specific module, you can use:
zef search module
in the list returned, you'll see in the first lines:
Zef::Repository::LocalCache... Module
...
which gives you a list of installed modules related to your question.
I am trying to build a .deb package for an application my company (and me) have been developing.
I'm trying to create a 64bit package on my 32bit ubuntu (12.04 LTS) using dpkg-buildpackage and I get the following warnings/errors:
dpkg-shlibdeps: warning/error: couldn't find library X needed by Y.so (ELF format: 'elf64-x86-64'; RPATH: 'some/path/that/does/not/exist')
When X is one of our compiled shared libraries, we get a warning. When it's a system library (like libgcc_s.so.1 and libstdc++.so.6) we get an error.
Why is the RPATH refers to a path that does not exist?
By the way, when I make a 32bit package (on our files that were compiled for 32bit of course) it only shows warnings (only about our proprietary .so files) but creates the .deb file.
If I could, I would have posted my debian folder content but I cant take files out of our network. I can type the relevant parts if its needed.
You need to install the 64-bits version of the library with apt-get (actually anything do, but this is the most easy):
sudo apt-get install libyouneed-dev:amd64
The trick here is the :amd64, which tells the package manager to install the 64-bit version of that package. The same applies for 32-bits libraries in 64-bit systems. It's called multiarch.
The package is looking at that path because that is where the libraries of 64-bits (or 32-bits) gets stored, but since you don't have it installed the path do not exist.
Install an amd64 chroot environment and build your package in there. This way you avoid the various multi-arch pitfalls, with the added benefit of having a clean, reproducible build.
There is a tool that makes this very easy: mk-sbuild.
You need to install ubuntu-dev-tools and sbuild.
Then, run mk-sbuild --arch=amd64 precise, which will setup the build environment for you.
Add yourself to the sbuild group: adduser <your user name> sbuild
Log out and log back in so your group membership will be reflected.
You can then build your package in the chroot:
sbuild -d precise --arch=amd64 name_of_package.dsc
This assumes you've already build the source package with debuild -S or similar.
I just built Rakudo and Parrot so that I could play with it and get started on learning Perl 6. I downloaded the Perl 6 book and happily typed in the first demo program (the tennis tournament example).
When I try to run the program, I get an error:
Divide by zero
current instr.: '' pc -1 ((unknown file):-1)
I have my perl6 binary in the build directory. I added a scripts directory under the rakudo build directory:
rakudo
|- perl6
\- scripts
|- perlbook_02.01
\- scores
If I try to run even a simple hello world script from my scripts directory I get the same error:
#!/home/daotoad/rakudo/perl6
use v6;
say "Hello nurse!";
However if I run it from the rakudo directory it works.
It sounds like there are some environment variables I need to set, but I am at a lost as to what the are and what values to give them.
Any thoughts?
Update:
I'd rather not install rakudo at this point, I'd rather just run things from the build directory. This will allow me to keep my changes to my system minimal as I try out different Perl6 builds (Rakudo * is out very soon).
The README file encouraged me to think that this was possible:
$ cd rakudo
$ perl Configure.pl --gen-parrot
$ make
This will create a "perl6" or "perl6.exe" executable in the
current (rakudo) directory. Programs can then be run from
the build directory using a command like:
$ ./perl6 hello.pl
Upon rereading, I found a reference to the fact that it is necessary to install rakudo before running scripts outside the build directory:
Once built, Rakudo's make install target will install Rakudo
and its libraries into the Parrot installation that was used to
create it. Until this step is performed, the "perl6" executable
created by make above can only be reliably run from the root of
Rakudo's build directory. After make install is performed,
the installed executable can be run from any directory (as long as
the Parrot installation that was used to create it remains intact).
So it looks like I need to install rakudo to play with Perl 6.
The next question is, where rakudo be installed? README says into the Parrot install used to build.
I used the --gen-parrot option in my build, which looks like it installs into rakudo/parrot-install. So rakudo will be installed into my rakudo\parrot-install?
Reading the Makefile, supports this conclusion. I ran make install, and it did install into parrot_install.
This part of the build/install process is unclear for a newbie to Perl6. I'll see if I can up with a documentation patch to clarify things.
Off the top of my head:
Emphasize running make install before running scripts outside of build. This requirement is currently burried in the middle of a paragraph and can be easily missed by someone skimming the docs (me).
Explicitly state that with --gen-parrot will install perl6 into the parrot_install directory.
Did you run make install in Rakudo?
It's necessary to do it to be able to use Rakudo outside its build directory (and that's why both the README and http://rakudo.org/how-to-get-rakudo tell you to do it.
Don't worry, the default install location is local (in parrot_install/bin/perl inside your rakudo directory).
In response to your update I've now updated the README:
http://github.com/rakudo/rakudo/commit/261eb2ae08fee75a0a0e3935ef64c516e8bc2b98
I hope you find that clearer than before. If you still see room for improvement, please consider submitting a patch to rakudobug#perl.org.