If true, makes Git check if converting CRLF is reversible when end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either directly or indirectly. For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for the current setting of core.autocrlf, Git will reject the file. The variable can be set to "warn", in which case Git will only warn about an irreversible conversion but continue the operation.
CRLF conversion bears a slight chance of corrupting data. When it is enabled, Git will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by Git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.
If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes. Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell Git that this file is binary and Git will handle the file appropriately.
Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished. In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data.
Note, this safety check does not mean that a checkout will generate a file identical to the original file for a different setting of core.eol and core.autocrlf, but only for the current one. For example, a text file with LF would be accepted with core.eol=lf and could later be checked out with core.eol=crlf, in which case the resulting file would contain CRLF, although the original file contained LF. However, in both work trees the line endings would be consistent, that is either all LF or all CRLF, but never mixed. A file with mixed line endings would be reported by the core.safecrlf mechanism.
core.autocrlf
Setting this variable to "true" is almost the same as setting the text attribute to "auto" on all files except that text files are not guaranteed to be normalized: files that contain CRLF in the repository will not be touched. Use this setting if you want to have CRLF line endings in your working directory even though the repository does not have normalized line endings. This variable can be set to input, in which case no output conversion is performed.
This obsolete system call is not supported by glibc. No declaration
is provided in glibc headers, but, through a quirk of history, glibc
versions before 2.23 did export an ABI for this system call.
Therefore, in order to employ this system call, it was sufficient to
manually declare the interface in your code; alternatively, you could
invoke the system call using syscall(2).
But still have issue on bison 3.0 (Ubuntu 14.04). The general solution to this is to downgrade to bison 2.7. I don't want to try this on my working computer.
VirtualBox+Ubuntu8.04+c32-build = work!!
I setup a VirtualBox with Ubuntu8.04. https://help.ubuntu.com/community/EOLUpgrades
Edit /etc/apt/sources.list, replace all the server with "old-releases.ubuntu.com".
Then install the required package:
Execute the following to run MPLAB X IDE:
/opt/microchip/mplabx/v3.26/mplab_ide/bin/mplab_ide
I installed the JRE in /usr/java. (ref here)
(java need to be in $PATH, or manually make symbolic link /usr/bin/java to the newly installed JRE java binary)
or on Ubuntu16.04 install JRE directly by:
I have a Chinese Windows 8, but it seems MPLAB X doesn't support Chinese and the error message during building project become Chinese and not readable on MPLAB X. I tried changing the system language but not work.
This could be workaround by removing the locale C:\Program Files (x86)\Microchip\MPLABX\v3.26\gnuBins\GnuWin32\share\locale.
(Just rename doesn't work, don't know why)
(2016/10/07) I got missing java.exe on another newly Win7
Changes to port a project between Windows and Linux MPLAB
Windows executables has suffix .exe, e.g. date.exe, while Linux doesn't
Windows path separate with slash "\", while Linux with backslash"/". Sometimes file path might be written in Windows form, e.g in nbproject/configurations.xml:
I write for myself to remember things, and it's just a note, or memo. Not always complete, or meaningful, and also not necessary created by me. Reference at will.