this is the very first time that I try to compile anything in Windows and it already gives me the creeps (not because of Windows that is).
I downloaded a dictionary from here:
https://www.j3e.de/ispell/igerman98/dict/igerman98-20161207.tar.bz2
When I extract the folder then there is a Makefile, so I think that I have to compile the progrmam first. I tried that with two methods: first Cygwin, second MinGW. Both programs are in my PATH.
I use the terminal of both programs to navigate to D:/igerman98 and there I enter
make
The first message I get is:
$ make
A default make target doesn't exist. You might want to use one of those:
make hunspell/de_DE.dic hunspell/de_DE.aff (or de_AT or de_CH)
make myspell/de_DE.dic myspell/de_DE.aff (or de_AT or de_CH)
make ispell/de_DE.aff ispell/de_DE.hash (or de_AT, de_CH ...)
make aspell/de_DE.rws (or de_AT, de_CH ...)
make ligature/rmligs
make isowordlist-de_DE (or de_AT, de_CH ...)
Did I forget an important one ?-)
So I enter again the following:
make hunspell/de_DE.dic hunspell/de_DE.aff
But then I get the following error:
$ make hunspell/de_DE.dic hunspell/de_DE.aff
test -e all.words.placebo.tmp || echo a > all.words.placebo.tmp
buildhash all.words.placebo.tmp ispell/de_DE_null.aff ispell/de_DE_null.hash
make: buildhash: Command not found
make: *** [ispell/de_DE_null.hash] Error 127
What am I doing wrong here? I just want de_DE.dic and de_DE.aff files to be created so I can use them with the spelling module in Textadept...
Under Linux, the program buildhash comes with the ispell-package. Under Windows, you can use: ISPELL for Windwos
Related
My knowledge of Make is small. I have been told that everything you put after make (that does not contain "-") is a target.
Well a building process I have is failing.
First there is a line
make path/to/configuration_file
configuration_file is not a target. It is a autogenerated configuration file buried inside the directory structure ("path/to") that is of the form
#
# Boot Configuration
#
#
# DRAM Component
#
CONFIG_DRAM_TYPE_LPDDR4=y
# CONFIG_DRAM_TYPE_DDR4 is not set
CONFIG_DDR_SIZE=0x80000000
#
# Boot Device
#
# CONFIG_ENABLE_EMMC_BOOT is not set
# CONFIG_ENABLE_NAND_BOOT is not set
CONFIG_ENABLE_SPINAND_BOOT=y
# CONFIG_ENABLE_SPINOR_BOOT is not set
CONFIG_EMMC_ACCESS_8BIT=y
# CONFIG_EMMC_ACCESS_4BIT is not set
# CONFIG_EMMC_ACCESS_1BIT is not set
so I cannot understand how this is a target. For reference, when I run make there is a Makefile but this Makefile does not reference this file.
Still this line is going well.
The path where it fails says
make diags
and I have verified there is no "diags" target.
I will print here the error file that can give us more info of what is happening
GEN cortex_a/output/Makefile
Init diag test "orc_scheduler" ...
remoteconfig: Failed to generate configure in cortex_a/soc/visio/tests/orc_scheduler!
Makefile:11 recipe for target 'orc_scheduler-init' failed
make[10]: *** [orc_scheduler-init] Error 25
At least what I would like to know is how to interpret this error message. I don't know what the "11" or the "10" or the "25" refers to.
make is fundamentally a tool for automatically running commands in the right order so you don't have to type them in yourself. So all the commands make runs are commands that you could just type into your shell prompt. And all the errors that those commands generate are the same ones that you would see if you typed the command yourself. So, looking at make to try to understand those errors is looking in the wrong place: you have to look at the documentation for whatever command was invoked.
A "target" is just a file that make knows how to build. The fact that when you typed make <somefile> is didn't give you an error that it doesn't know how to build <somefile>, means that <somefile> is a target as far as your makefiles are concerned.
The error message Makefile:11: simply refers to the filename Makefile, line 11, which is where the command that make ran, that failed, can be found. But this likely won't help you solve the problem of why the command failed (unless the problem is you invoked it with the wrong arguments and you need to adjust the makefile to specify different arguments).
The command that failed generated the message:
remoteconfig: Failed to generate configure in cortex_a/soc/visio/tests/orc_scheduler!
I don't know what that means, but it's not related to make. You'll need to find out what this remoteconfig command is, what it does, and why it failed. It's unfortunate that it doesn't show any better error message as to why it failed to "generate configure", but again there's nothing make can do about that.
If you want to learn more about make you can look at the GNU make manual (note, GNU make is only one implementation of make; there are others and they are fundamentally the same but different in details).
It was my understanding that grub supports a small subset of bash. Their documentation doesn't go into super detail, other than it "supports conditionals", etc.
I am trying to run a simple if.
grub> if [ "${myvar}" = "fred" ]; then
> echo "test"
> fi
error: can't find command `['.
Anybody have an idea? I am using grub2-efi 2.00.
You are missing a grub2 module in order to run if tests.
I'm running Gentoo on a PowerPC system (PPC64 G5 machine) and doing a default grub-mkconfig then booting from it gives me the error in your question.
Since bash has that syntax support, I figured it was simply a grub module that needed to be added (I had been doing work with grub modules recently).
tl;dr: You need to load the appropriate grub module and then the error goes away.
The first step is to find out what modules you have. For me, it's whatever is available in my /boot/grub/powerpc-ieee1275/ folder.
There's also modules in /usr/lib/grub/powerpc-ieee1275/.
I wrote up a list of modules I thought I needed:
normal
eval
read
test
test_blockarg
trig
true
I then added them to my /etc/default/grub file:
GRUB_PRELOAD_MODULES="normal eval read test test_blockarg trig true"
I did not find an entry for GRUB_PRELOAD_MODULES in the config file, so I had to do some searching to find out how. I want these modules to be added every time I generate the grub config file, which means putting them in the 00_header portion of grub.
Then I recreated the configuration file:
grub-mkconfig -o /boot/grub/grub.cfg
The modules were in the header and things worked perfectly on reboot.
If I had to guess: you probably only need the test module to enable if statements.
I'm trying to run a Perl script called WyD using Cygwin on Windows. Cygwin is installed at C:\cygwin64, and WyD is installed at C:\wyd\wyd.pl. Both are in the Windows PATH environment variable as C:\cygwin64 and C:\wyd respectively.
When running WyD with bash/Mintty using:
wyd.pl -b -e -t -s 3 -o "OUTPUTTEDWORDLIST" "TARGETFOLDER"
...I get the following error:
Can't locate object method "init" via package "wlgmod::odt" (perhaps
you forgot to load "wlgmod::odt"?) at /cygdrive/c/WYD/wyd.pl line 284.
Sometimes wlgmod::odt is replaced with wlgmod::doc or any other document type, but running the script always generates that same basic error. A previous answer to this question recommended installing several dependencies, which turned out to be a mere copy-paste of an answer for Ubuntu systems, and didn't solve the error, so I've decided to start at the beginning and re-ask the question with more details. I also have all Perl packages in the Cygwin installer installed.
After everything I've tried and done to get this script working, I can personally think of two possible causes for the error. Think of these as a guide more than anything else.
The error above references line 284 in the wyd.pl script, so it's possible that something in that script is hardcoded so that it doesn't work with Cygwin/Windows, or just generally has a compatibility bug. I don't understand Perl, so I can't confirm this.
I notice that the installation of WyD at C:\wyd contains a folder called wlgmod, and that folder contains all the files that the above error seems to be looking for; doc.pm, html.pm, jpeg.pm, etc. If those files exist in that directory but bash is unable to find them, maybe it's due to the fact WyD needs to be run from within Cygwin itself. I've only recently thought about this possibility, and my knowledge of both Cygwin and WyD is too sparse to definitively know how both work. Is it even possible to run WyD from within the Cygwin folder? It's not a package so can't be installed as one, and therefore I'm not sure how that would work.
Here are the relevant sections of the script:
# Module hash containing module name and supported file extensions
# Multiple extensions are seperated using ';'
my %wlgmods = (
'wlgmod::strings', '', # only used with command-line switch
'wlgmod::plain' , '.txt', # used for all MIME text/plain as well
'wlgmod::html' , '.html;.htm;.php;.php3;.php4',
'wlgmod::doc' , '.doc',
'wlgmod::pdf' , '.pdf',
'wlgmod::mp3' , '.mp3',
'wlgmod::ppt' , '.ppt',
'wlgmod::jpeg' , '.jpeg;.jpg;.JPG;.JPEG',
'wlgmod::odt' , '.odt;.ods;.odp'
);
...
# Initialize possible modules
foreach(keys %wlgmods) {
eval("use $_;");
my $ret = $_->init(); # line 284
# If module failed, add errortext and remove from hash
if($ret) {
$retvals .= "$_: $ret\n";
delete $wlgmods{$_};
$ret = "";
}
}
As part of a little project, I'm writing a shell in Ada. As such, when I was investigating the system calls, I learned that there are three ways to do it.
The POSIX system calls, which are probably the least reliable.
Passing the arguments along to C's system(), which I didn't really want to do, since this was about writing the emulator in Ada and not C.
Using GNAT's runtime libraries.
I chose to go for the last option, considering this to be the most "Ada-like" of the choices. I found a code snippet on RosettaCode here. I copied and pasted it and compiled it after changing the "cmd.exe" to "ls" and removing the second argument definition. However, nothing happens when I run the executable. The shell just goes right back to the prompt. I have tested this on two different computers, one running Fedora 21, the other Debian Jessie. Here's what I've done to test it:
Seen if lacking an arguments string caused it
Checked if any of the file descriptors in GNAT's libraries are mis-named
Redirected both stderr and stdin to stdout just to see if GNAT was dumping them to the wrong FD anyway.
Looked thoroughly through the System.OS_lib library file, and there seems to be no reason.
Googled it, but GNAT's own page on the GCC website is very poorly documented.
For now I'm using the C.Interface system in the preparation of my shell, but I'm dissatisfied with this. I'm new to Ada and have only been tinkering with it for a month or so now, so if there's some kind of Ada wisdom here that would help I'm not in on it.
UPDATE: I have tried running it with absolute path, both to /usr/bin and /bin locations, and it doesn't work. Interestingly, the result code returned by the operating system is 1, but I don't know what that means. A quick search suggests that it's for "all general errors", and another site suggests that it's for "incorrect functions".
I had to tweak the RosettaCode example a little to run /bin/ls on Debian Linux, but it does run as expected...
with Ada.Text_IO; use Ada.Text_IO;
with Gnat.OS_Lib; use Gnat.OS_Lib;
procedure Execute_Synchronously is
Result : Integer;
Arguments : Argument_List :=
( 1=> new String'("-al")
);
begin
Spawn
( Program_Name => "/bin/ls",
Args => Arguments,
Output_File_Descriptor => Standout,
Return_Code => Result
);
for Index in Arguments'Range loop
Free (Arguments (Index));
end loop;
end Execute_Synchronously;
Changes :
my Gnat (FSF Gnat 4.92 from Debian Jessie) warned about System.OS_Lib, recommending Gnat.OS_Lib instead. (Which simply renames System.OS_Lib .... why???
System.OS_Lib comments:
-- Note: this package is in the System hierarchy so that it can be directly
-- be used by other predefined packages. User access to this package is via
-- a renaming of this package in GNAT.OS_Lib (file g-os_lib.ads).
Program name including path.
Arguments. The first time I ran it, it displayed the details of "ls" itself, because it was given its own name as the first argument, so I deleted that to see the current directory instead.
Notes :
the best information ot the available subprograms and their arguments is usually in the package specs themselves in the "adainclude" folder : this is /usr/lib/gcc/x86_64-linux-gnu/4.9/adainclude on my Debian installation, locate system.ads will find yours. The specific files are: s-os_lib.ads for System.OS_Lib which exports Spawn and Standout, and a-textio.ads for Ada.Text_IO.
Standout is not the preferred way of accessing Standard Output : it's a file descriptor (integer), the preferred way would be the Standard_Output function from Ada.Text_IO which returns a File. However there doesn't seem to be an overload for Spawn which takes a File (nor would I expect one in this low level library) so the lower level file descriptor is used here.
Absent a shell, you'll need to search the PATH yourself or specify a full path for the desired executable:
Spawn (
Program_Name => "/bin/ls",
…
);
I have tried running it with absolute path…neither /usr/bin nor /bin locations work.
Use which to determine the full path to the executable:
$ which ls
/bin/ls
I am trying to build Win32::Daemon by myself. The reason I not use CPAN is because I want to dig deeper into the working of Perl modules. In the end I hope to come up with a solution for another problem by seeing this working (not of importance here).
I would see 3 options to build the module: cygwin, mingw, microsoft compiler (cl)
On MinGW it reports that it is not supported (simple if in the Makefile.PL) which expands to more errors once I modify the check to match MinGW
On Cygwin it complains about tchar.h which, as I found out, is a Windows header (MinGW does have it).
But my real goal anyway is building it with the MS compiler, so while any compilation that does not require any special libs (like it would do with cygwin I suppose) will more.
So now here goes my nmake output from running just name /f Makefile:
NMAKE : fatal error U1073: "C:/Program" could not be created.
Stop.
I roughly translated the error message from german, but the statement is simple.
What I see here seems to be a path problem (probably the spaces). I also notice the forward slash. The Makefile was created by the Makefile.PL script (I am using Active Perl v5.12.1):
use strict;
use warnings;
use Config qw(%Config);
use ExtUtils::MakeMaker;
unless ($^O eq "MSWin32" || $^O eq "cygwin") {
die "OS unsupported\n";
}
require Win32;
my %param = (
NAME => 'Win32::Daemon',
VERSION_FROM => 'Daemon.pm',
DEFINE => '-DPERL_NO_GET_CONTEXT',
OBJECT => 'CCallbackList$(OBJ_EXT) CCallbackTimer$(OBJ_EXT) Constant$(OBJ_EXT) CWinStation$(OBJ_EXT) Daemon$(OBJ_EXT) ServiceThread$(OBJ_EXT)',
XS => { 'Daemon.xs' => 'Daemon.cpp' },
);
$param{INC} .= ' -EHsc' if $Config{'cc'} =~ /^cl/i;
$param{NO_META} = 1 if eval "$ExtUtils::MakeMaker::VERSION" >= 6.10_03;
WriteMakefile(%param);
sub MY::xs_c {
'
.xs.cpp:
$(PERL) -I$(PERL_ARCHLIB) -I$(PERL_LIB) $(XSUBPP) $(XSPROTOARG) $(XSUBPPARGS) $*.xs >xstmp.c && $(MV) xstmp.c $*.cpp
';
}
I don't know much about the MakeMaker but I don't see anything here that I could fix and would expect that it boils down to fixing the Makefile itself by hand. I tried a couple of things like quoting but nothing helped.
The thing is, I am used to problems like this when building on Windows, but normally this is for tools that were created for Unix. This one is explicitly ONLY Windows and so I would expect it to work out of the box. So I figure that I am doing something wrong.
Any help on where to find the solution?
Thanks in advance.
Edit/Addition: I tried this on another Win7 machine with Active Perl 5.16.x and it worked like a charm. I looked at the different output from this machine and the current one which fails when running perl Makefile.PL and I recieve the following output:
... Detected uninstalled Perl. Trying to continue.
Unable to find a perl 5 (by these names: C:\Program Files\Perl64\bin\perl.exe perl.exe perl5.exe perl5.12.1.exe miniperl.exe, in these dirs: . [...] C:\Program Files\Perl64\site\bin C:\Program Files\Perl64\bin [...])
Have \progra~1\perl64\lib
Want \temp\perl---please-run-the-install-script---\lib
Writing Makefile for Win32::Daemon
I truncated the output. Now please someone explain to me: Why can I run perl Makefile.PL or perl -v but it does not find my Perl in the exact directory it is in? I reinstalled it but it did not work...
Okay I finally seem to have solved this after hours of searching. The problem lies within multiple issues.
The first command of "uninstalled perl" does not make any sense to be, but you can fix it, by supplying perl Makefile.PL PERL_SRC="C\:Program Files\Perl64". Warning: This did not work in a command shell for me, I had to use powershell, because he would not treat the path correctly. You maybe need to juggle with this a bit. Note: In the end I fixed it by installing the original Active Perl, not the one provided by my installer (company software distribution)
Now to the issue of not finding perl: This is a problem with spaces in the path. I fixed this (seemingly) by creating a symlink without spaces. Now perl Makefile.PL does not throw any errors, but nmake -f "Makefile" failed. So the solution really was: Do not have spaces in your perl-path! This sucks, and quite frankfly in 2012 this shouldn't be a problem any more but here you go.
Thanks for all the effort everyone put in, this was a tough one to solve.