Windows XP, Erlang R13B02 (erts-5.7.3)
Today werl desn't want compile any erlang file
c(binm).
** exception error: undefined function compile:file/2
in function c:c/2
Yesterday all work.
P.S install R14B03, can't compile again
That is a very odd error. Have you by accident deleted the compile.beam file from your OTP installation? A re-installation of R13B02 might solve it, if you don't want to change the OTP version.
But if you don't need to use R13B02 for any particular reason, I recommend taking the opportunity to uninstall it and install the latest version (R14B03) instead (http://www.erlang.org/download.html). There have been many improvements, in particular regarding type specifications.
What does io:format("~p~n", [code:get_path()]). print? It should contain a directory like somepath/lib/compiler-4.7.2/ebin. Check that that directory actually exists, and that it contains the file compile.beam.
Related
I am trying to use the latest version of the appImage-builder because appimages of my application built with the old version of appImage-builder do not run on ubuntu 22.04 anymore. So I got the order to try and see if it works with the new appImage-builder.
Currently (June 2022), only versions below 1.0 which are based on ubuntu 18.04 are available on docker (which we previously used to build our appimage).
The newer versions are available via github (https://github.com/AppImageCrafters/appimage-builder/releases).
However, I seem to be unable to execute:
appimage-builder --generate
or
appimage-builder --recipe AppImageBuilder.yml
Is there any documentation available on how to correctly use the .appimage version of appImage-builder? All I could find in https://appimage-builder.readthedocs.io/en/latest/ seems to refer to the docker version or a manually built version of appImage-builder.
Depending on the error message you get, there could be a couple of issues at play here.
If you got an error related to FUSE, then you need to install the libfuse2 package with apt install libfuse2. AppImages rely on libfuse2, but Ubuntu has stopped including it since 22.04, in favor of libfuse3.
If you get an error related to "file not found", then it could be that you do not have AppImageLauncher installed. Sadly, with type 2 AppImages the design decision was taken to modify the ELF header of the executable with 3 magic bytes at offset 8 of the executable. This means that Linux linkers will not run the file. AppImageLauncher actually copies the file to a temporary directory and zeroes out the magic number in order to be able to execute it.
A good starting point for debugging issues like this is to run the strace command, which will let you see which system call likely cause the error. Keep in mind that if you try to execute a file and you get File not found, it might mean that the linker specified by the file can not be found on the system or the ELF header is not valid. You can also run the executable by using the linker directly, which might give you more clues. For example with: /lib64/ld-linux-x86-64.so.2 <NAME-OF-YOUR-EXECUTABLE>.
I have been trying to test a code to connect to MySQL using C++ on a MacBook Pro, but I always get an error about boost/filename.hpp not found. I fix that by adding a full path on e.g. /usr/local/boost_1_64_0/boost/filename.hpp.
This fixes an error for one #include, when I compile again I get the same error on another line.
It will take me forever to do that (correcting the path all the time). I then downloaded MySQL-Connector-C++ using brew - which is now located at /usr/local/Cellar/mysql-connector-c++/1.1.9/.
Within the Cellar folder there are boost, mysql, openssl directories.
Can anyone please tell me how I can use this to test my code, run a simple query, and where do I put my c++ file I've created and need to compile?
I have written the code but I can't test it, it's private and for an organization which gave me the task.
I have been trying to figure out how to avoid correcting paths for more than three days now, followed all the instructions from the manual from the MySQL website.
I am trying to install the YAML 1.2 extension to PHP 5.6 under IIS 10 (Windows 10). I am using http://pecl.php.net/package/yaml/1.2.0/windows to download the files.
I have downloaded the PHP 5.6 non-thread-safe DLL (x86 to match my version of PHP), copied php_yaml.dll to my extension directory, copied yaml.dll to C:\Windows\System32 (which is reported as one of the paths in phpinfo()) and added extension=php_yaml.dll to my php.ini. I've verified with phpinfo() that the correct php.ini file is being loaded, and commenting out other extensions removes them from the output of phpinfo().
However, YAML doesn't appear in the output of phpinfo() and the functions are not loaded. Running php-cgi.exe -v from the command line gives a warning:
PHP Warning: PHP Startup: Unable to load dynamic library 'C:\PHP\php_5_06_14\ext\php_yaml.dll' - The specified module could not be found.
in Unknown on line 0
The file exists at the location specified and the permissions appear to be correct. What else can I do to get it working?
As far as I can tell, the use of PECL as package manager is being in dropping.
Having to install extensions in a server makes things more complicated and it depends on the environment, permissions, etc.
I'm sure someone could help you solve that (I haven't work on windows in years, so I can't)
But, instead I suggest you another solution. Maybe you can opt for it, maybe you have to stick with the extension, but, in case you can actually look for other option, I suggest you to use another library.
https://github.com/symfony/yaml
And, you could use Composer to install your libraries, I suggest you take a look at it.
Again, it may be for you or not, but I think this would be a lot easier.
I hope that helps.
I put the path to my extension directory in the path environment variable. That fixed the issue for me.
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll
I am now trying to install mingw for a couple of hours, however I keep on getting the following error message:
"install: gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
installing gcc-c++-4.8.1-4-mingw32-bin.tar.lzma
mingw-get-gui: * ERROR * unexpected end of archive reading header record"
and cannot find any solution to my problem. I tried to reinstall 7zip, because I thought it may caused from that. I am trying to install gcc on a 32-bit Windows 7. I would be really happy for any suggestions.
Bye!
Even though this is an old question, I will post an answer, in case other users come across this again.
I encountered the same problem:
at first I did not notice that something went wrong with the installation/upgrade itself, because the graphical update manager showed a line like "everything went successful" ...
if I had bothered to look into the log details, I would have seen the error messesage mingw-get-gui: * ERROR * unexpected end of archive reading header record and immediately known, that something went wrong (its really misleading, to show a dialog saying that a task was completed successfully when there were errors!).
But pertaining to your problem (or at least this was, what caused mine):
Cause
most likely something went wrong, when the mentioned archive file was downloaded. Unfortunately, mingw-get seems to ignore download errors and continues as if nothing went wrong... thus the error message archive header record is invalid, because it is not really an archive file, but a text file containing the HTML error message.
To complicate things further, mingw-get caches these files and when you try to re-install the packages it uses these invalid, cached files.
Solution
One way of fixing this, would be to delete the cached files and then re-install the package.
The cached files should be at
<mingw directory>\var\cache\mingw-get\packages
e.g.
C:\MinGW\var\cache\mingw-get\packages
Side Note: if you "lost" the error message like me, and don't know, for which packages there was an error, you can search the cache directory for files which contain the HTML error message, e.g. a search term like <html> should work; also these files are quite small, but there may also be other valid packages with small file size to this is no unambiguous criterion
If you continue to get error messages * ERROR * unexpected end of archive reading header record with the mingw-get tool you could also try to download the file manually and place it in the folder for the cached packages.
For re-installing the packages you could use the graphical interface of mingw-get (e.g. remove and then install the package) or, for example the command line version
mingw-get --reinstall install <package name>
for mingw packages the <package name> is usually just the prefix of the file name (before the first version number), e.g. for
libiconv-1.14-3-mingw32-dev.tar.lzma
the package name would be libiconv. For msys packages the package name usually has the prefix msys-, e.g. something like msys-libopts
(you should be able to see if it's a mingw or a msys package by looking at the part of the file name that comes after the first version number, e.g. for libiconv-1.14-3-mingw32-dev.tar.lzma: ...3-mingw32-de...)