I'm having the strangest issue while trying to build and install muParser on my windows machine. As suggested by the installation guide, I just cd into the build folder, and run
make -f makefile.mingw
This should be all well and good standard procedure. However, I can't make sense of the output from the command:
if not exist obj\gcc_static_rel mkdir obj\gcc_static_rel
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
Now... at this point, I'm really confused. Because according to the title of the command prompt window, I'm still INSIDE the make command. So, I type "exit" at the "prompt"
g++ -c -o obj\gcc_static_rel\muParser_lib_muParser.o -DNDEBUG -O2 -D_WIN32 - I..\include -MTobj\gcc_static_rel\muParser_lib_muParser.o - MFobj\gcc_static_rel\muParser_lib_muParser.o.d -MD -MP ../src/muParser.cpp
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
The command appears to "step" through it's next function. I continue to type exit at the "prompt" and the command appears to continue stepping until it's done. However, after exiting completely, I can't see any results and it appears nothing's actually been done.
Also, this doesn't have anything to do with the command prompt. I even wrote a python script to cd into the directory and call make, and the output still displayed a windows-style command prompt - complete with the copyright Microsoft line etc., and waited for an input. I typed exit the same way until the process exited back to python.
Now, I might be going insane, but I'm really confused. Asking on the forums yielded no help, the only response is that "the windows build should be working."
Does anyone know what's going on???
I downloaded the muParser package and tried to build it. I got the same strange behaviour from make as you did. Then I realised I only had MSYS-make installed, not MinGW-make (the first one is intended for use in the MSYS shell, the second one for use in the Windows cmd shell).
Unfortunately, installing and using mingw32-make gave a different error, but googling that lead me to this page, where it was suggested to rename sh.exe in the MSYS directory. After doing that, running mingw32-make -f makefile.mingw succesfully built (the static version of) the library.
The other method you and shellter are using of running ./configure; make in the MSYS shell, also fails to build the example for me. It does build the dll version of the library in this case, instead of the static version; perhaps this is why the example fails to build.
(You might want to add a tag for 'make' or 'gmake', that should boost the number of eyes looking at your problem).
Looking at the makefile.mingw, I'm surprised to see statements like '-if not exist ..', that is .bat file syntax.
I ran ./configure ; make and it got past the error messages you mention, but I'm seeing a bunch of error messages like undefined reference to mu::ParserError: , so I'm probably missing libraries to make it work completely. I'll have to leave it at that, and hope that it helps you. Note that I didn't use make -f makefile.mingw. After using configure, make just picked up the newly created Makefile, and it worked (excepting the library problems ;-)
(When you say forums, did you mean the mingw forums? If not, try looking around here. The search functionality is pretty good.)
I hope this helps.
Related
On Windows, trying something with gtk+. I have downloaded Msys2, along with gtk+3.0.
Successfully compiled all the gtk+3.0 examples in the msys2 mingw-w64 terminal.
Now I want to move a bit further to try work without the msys environment.
I opened up cmd and navigated to where the example executables are compiled. Then I fired them up by typing "example.exe".
libgio-2.0-0.dll missing, not surprised. I go back to check the PATH environment of the msys environment, PATH=/mingw64/bin/:/usr/local/bin:/usr/bin/:/bin:/c/Windows/System32:..blablabla
So in the cmd environment I did set PATH=%PATH%;pathto/mingw64/bin; and run example.exe again.
This time it gave a very strange error cannot find entrypoint inflateValidate (in dll libpng16-16.dll)
So I checked, indeed there was no inflateValidate function in the dll. it seemed to me that something thought the function is in the dll and tried to call it but because it doesn't exist so it failed. What I don't understand is that why did it not fail in the msys environment but failed in the windows environment. And does that bring any impact to me if I am going to ship any gtk application? I thought simply distributing the relevant dll would be enough.
I have tried instead of adding the mingw64/bin path to the PATH variable, but copying the required dll the the execute location 1 by 1, but at the end it still gave the same error.
I have also tried to search for other libpng*.dll in my computer, none of them contained the inflateValidate function.
If anyone know whats going on please shed some light to the question.
I might be very late to the party but I ran into the same issue yesterday (missing the inflateValidate symbol) and after checking the contents of the zlib1.dll file could ascertain that the function is just not there.
I downloaded another version (specifically this one https://sourceforge.net/projects/uqm-mods/files/latest/download, though I am in no way affiliated to this project) and saw that the inflateValidate symbol was indeed declared, so I suppose that the zlib bundled with your files is not up to date with the libpng requirements.
This solved my problem. I hope it solves yours too.
I have installed dmd and ddt as instructed:
DMD64 D Compiler v2.066.0
Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
but when I create a dub project in eclipse, I dot an error that says standard libray not found:
(source: p.im9.eu)
any ideas?
OS: Mac OSX 10.9
Eclipse: 4.4
DDT: 0.10.2
I've also posted a temporary workaround in the discussion group (link):
# cd /usr/share/dmd
# mkdir dummy
# mkdir dummy/bin
# touch dummy/bin/dmd
# launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
# killall Dock
Note that the DUB_COMPILERS_PATH variable shouldn't point to the binary itself, it acts like an additional PATH variable, i.e should contain bin dirs.
To make this survive a reboot, add the launchctl line to /etc/launchd.conf:
launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
You might need to create it if it doesn't already exist.
This seems to be a reported bug of DDT:
https://github.com/bruno-medeiros/DDT/issues/75
Basically, it boils down to the directory structure of the installed dmd. As they are many distributions and many installers, each one with its own convention, DDT missed some.
They should be added and recognized shortly, in the pending release.
Please follow the reported issue on github/DDT page.
Yes, I know this thread is really old, and yes DDT seems to be no longer in development.
However, for those of us who are new to D, Eclipse and DDT, and relatively new to using Linux (I'm using Mint 19.3), I have the following solution which worked for me. No doubt this is common knowledge somewhere, but I had to scratch around quite a lot to discover this. (Of course, your dmd version number may be different.)
Note that dub is automatically installed along with dmd in:
$HOME/dlang/dmd-2.090.1/linux/bin64/dub
The command
source ~/dlang/dmd-2.090.1/activate
will modify the $PATH variable to allow access to the compiler.
NOTE that this only changes the path for the shell where the command is issued... and only for the current session!
If you want the path change to be permanent (who doesn't?), add the following to ~/.profile using a text editor, e.g. nano ~/.profile or xed ~/.profile , etc.:
# Add dlang dmd compiler path
if [ -d "$HOME/dlang/dmd-2.090.1/linux/bin64" ] ; then
PATH="$HOME/dlang/dmd-2.090.1/linux/bin64:$PATH"
fi
This corrects the Eclipse error:
"D Standard Library [Error: none found]"
in the Project tree, and also allows dub to be run from any directory, e.g. from a terminal.
HTH.
I desperately need your help! I need to compile a perl script to an executable so that it can be run in windows without having perl installed. I know it is not a good idea to do this , but I absolutely need it for the users of my script.
I have searched (a lot!) and decided the best solution is to use PAR::Packer. Yet I have been trying to install for something like 10 days now with no success…
I ve tried all possible combinations of perl installation (activestate, strawberry, 5.10, 5.14, 5.16) and PAR versions, but I haven’t found the combination that really works….
I tried this link: http://www.nicholassolutions.com/tutorials/perl-PAR.htm
And this: http://www.rabbibob.com/index.php/PAR_Compiling_Perl_scripts_into_executables#Can.27t_find_par_loader
And various from this site..
Anyway, right now, I have installed (with the above instructions):
Strawberry perl 5.16.3001
PAR-1.007
The error I get now when I try to run
pp –o script.exe script.pl
is that:
pp is not recognized as an external or internal command, operable program or batch file
indeed I don’t find the relevant pp.bat in the bin. For earlier versions of par, this bat was created, although there other missing files were appearing when
running pp….
My path variable contains:
C:\strawberry\c\bin;C:\strawberry\perl\site\bin;C:\strawberry\perl\bin
I also used PAR::Packer 1.0.14 but I get errors in the installation, something like
dmake.EXE: Error code 255, while making 'subdirs'
So, my question is: does anyone know a sure way this can work?? I am really frustrated and really pressed, every help will be deeply appreciated.
Thanks a lot!
I have used PAR to pack some scripts for other users. This has worked very well.
My old setup was done long ago. I have a new laptop and I tried to reproduce you error - but it seems like it just works.
My steps:
downloaded and installed strawberry-perl-5.18.1.1-64bit.msi
Install PAR::Packer with the cpan client
Create a testscript and type
pp -c -o test.exe test.pl
This produce the file test.exe - and it works fine.
the executable file pp is located in C:\strawberry\perl\site\bin\pp and was installed when i installed PAR::Packer.
If you cant find pp on you system you might want to check you installation of PAR::Packer.
I hope this helps :)
I've been trying for a week to get F# interactive working in Emacs and I haven't been able to.
The problem is that whenever I run "fsi" or "fsharpi" (either using fsharp mode or in a shell buffer), the buffer becomes unresponsive. I check the system monitor and see a mono process using 100% CPU and obviously anything I type doesn't get evaluated.
I've tried this on Emacs 24.1 and 23.2; also on OS X, Linux Mint and Fedora, and all cause the same exact problem.
I've tried different versions of mono (2.10.9, 3.0 and 2.8 on OS X; 2.10.8.1 on Linux Mint, can't remember on Fedora). I've also tried F# 2.0 and 3.0; all with same results.
I've also tried passing in "--no-gui" and "--readline" when launching the interpreter to no use.
Here's basically what happens
bash-3.2$ fsharpi
Microsoft (R) F# 3.0 Interactive version (Mono build)
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> - 1+2;;
# after waiting for a minute, I kill the mono process
Killed: 9
bash-3.2$ bash: syntax error near unexpected token `;;'
However, the interpreter does work when running it on an "ansi-term" buffer:
bash-3.2$ fsharpi
Microsoft (R) F# 3.0 Interactive version (Mono build)
Copyright (c) Microsoft Corporation. All Rights Reserved.
For help type #help;;
> - 1+2;;
val it : int = 3
I want to use it with fsharp mode so that I can send code to the interpreter easily.
I haven't seen anyone having problems of this kind online, and resolving this would make development so much more convenient.
Any ideas on how to get this working?
Edit: as expected, running it in comint mode also "hangs" (comint is what fsharp mode uses).
What version of fsharp-mode are you using? The last update (v0.3) was just after the release of VS2010 (F# 2.0), and the release notes mention that an infinite-loop bug was fixed in that version.
Another possibility -- the last update to fsharp-mode predates Mono's support for F#, so my guess is that some piece of code in the Intellisense helper project (in the /src folder of the fsharp-mode code) is relying on Windows-specific behavior and breaking when you run it on Mono.
I think your best bet to get this working is to repost your question on the fsharp-opensource mailing list, as a number of people on there are running F# on Mono and might know how to fix the problem.
EDIT: The answer from the mailing list post is to pass in the --readline- flag. The trailing - turns readline off and fixes the problem.
The answer is to run the F# interpreter with the option "--readline-".
It should be solved (no need for this command line argument) in the Github repository https://github.com/fsharp/fsharp
What is a command line compiler?
Nowadays, you tend to have environments in which you develop code. In other words, you get an IDE (integrated development environment) which is comprised of an editor, compiler, linker, debugger and many other wonderous tools (code analysis, refactoring and so forth).
You never have to type in a command at all, preferring instead a key sequence like CTRLF5 which will build your entire project for you.
Not so in earlier days. We had to memorize all sorts of arcane commands to get our source code transformed into executables. Such beautiful constructs as:
cc -I/usr/include -c -o prog.o prog.c
cc -I/usr/include -c -o obj1.o obj1.c
as -o start.o start.s
ld -o prog -L/lib:/usr/lib prog.o obj1.o start.o -lm -lnet
Simple, no?
It was actually a great leap forward when we started using makefiles since we could hide all those arcane commands in a complex file and simply execute make from the command line. It would go away and perform all those commands for us, and only on files that needed it.
Of course, there's still a need for command-line compilers in today's world. The ability to run things like Eclipse in "headless" mode (no GUI) allow you to compile all your stuff in a batch way, without having to interact with the GUI itself.
In addition, both Borland (or whatever they're calling themselves this week) and Microsoft also provide command-line compilers for no cost (Microsoft also have their Express editions for free as well).
And gcc is also a command-line compiler. It does its one job very well and leaves it up to other applications to add a front end, if people need that sort of thing.
Don't get me wrong. I think the whole IDE thing is a wonderful idea for a quick code/debug cycle but I find that, once my applications have reached a certain level of maturity, I tend to prefer them in a form where I can edit the code with vim and just run make to produce the end product.
A command-line compiler is one that you run from the command line.
You type in gcc filename.c to compile a file (or something like that). Almost all compilers have a command-line version, and many have GUIs where you never see the command line, but the command line is still there. – Bill K Oct 5 at 16:27
(Bill K provided a nice answer in the comments... copied here and lightly edited by Mark Harrison, set to community wiki so as not to get rep.)