2011-02-11

Denying non-fast-forward and SourceForge

Well, I have it from good source that deleting commits, on a public source, is actually fine if you have a good reason to do so. But what if that public source happens to be a git repositoty on SourceForge?

Let's say you wanted to push some code modifications, so you added a source (or so you thought), but realize after commit & push, that what you really added was the binary rather than the .c. Don't want your public repo to be polluted by unneeded binaries.

So you tried:
git reset --hard HEAD~1
git push origin +master:master
or
git commit --amend
but every time you push you get the error:
error: denying non-fast-forward refs/heads/master (you should pull first)
To ssh://USER@PROJECT.git.sourceforge.net/gitroot/PROJECT
 ! [remote rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'ssh://USER@PROJECT.git.sourceforge.net/gitroot/PROJECT'
What gives?

A good search will of course lead you to ticket #9187 and receive.denyNonFastforwards being set to true by default on the remote git repository provided by SourceForge.

How can you edit your remote config to unset denyNonFastforwards? Easy:
ssh -t USER,PROJECT@shell.sourceforge.net create
[USER@shell-24010 ~]$ sf-help
(...) 
Your project DSCM repositories are here (use adminrepo for CVS and SVN):

    /home/scm_git/U/US/USER.u
    /home/scm_git/P/PR/PROJECT
(...)
[USER@shell-24010 ~]$ cd /home/scm_git/P/PR/PROJECT
[USER@shell-24010 PROJECT]$ ls -alFh
total 12K
drwxrwsr-x 3 dummy PROJECT   80 Nov 29 19:15 ./
drwxr-xr-x 3 root  root    4.0K Feb 10 21:58 ../
drwxrwsr-x 7 dummy PROJECT 1.0K Nov 29 19:15 PROJECT/
[USER@shell-24010 PROJECT]$ cd PROJECT
[USER@shell-24010 PROJECT]$ ls -alFh
total 48K
drwxrwsr-x   7 dummy PROJECT 1.0K Nov 29 19:15 ./
drwxrwsr-x   3 dummy PROJECT   80 Nov 29 19:15 ../
-rw-rw-r--   1 dummy PROJECT   23 Nov 29 19:15 HEAD
drwxrwsr-x   2 dummy PROJECT   80 Nov 29 19:15 branches/
-rw-rw-r--   1 dummy PROJECT  126 Nov 29 19:15 config
-rw-rw-r--   1 dummy PROJECT    5 Nov 29 19:15 description
drwxrwsr-x   2 dummy PROJECT 1.0K Nov 29 19:15 hooks/
drwxrwsr-x   2 dummy PROJECT   80 Nov 29 19:15 info/
drwxrwsr-x 133 dummy PROJECT 5.0K Feb 10 21:41 objects/
drwxrwsr-x   4 dummy PROJECT   80 Nov 29 19:15 refs/
Yay, there's a config there:
[USER@shell-24010 PROJECT]$ vi config
Then remove/unset that pesky denyNonFastforwards and you're good to go.

2011-01-31

memory leak detection in MSVC

Keep losing that link - here it is.

2011-01-17

Windows backup and MediaID.bin

Whoever thought it would be a good idea to make Windows backup dependent on a small MediaId.bin file residing on the backup target, outside of the actual backup directory, oughta get fired.

So, let's say you're using a samba drive as your backup destination, where there already exists a bunch of directories. Windows will create its own WindowsImageBackup directory in there, and that's fine.

Then, a few month later, you're cleaning up the root of your backup directory, and seeing this small MediaID.bin, which doesn't seem to serve any purpose (if it's that small, it can't be that important - plus all it really contains is a 16 bytes payload).

Bad move: now NONE of your backup archives will work.

If you need a unique ID to identify that a backup file is legitimate, how about you add it to the backup file itself instead of creating an extra MediaID.bin, outside of the backup directory, that screams "delete me"?

2011-01-16

Virtual Store, Windows 7 and HyperTerminal

Let's do things in order then.
  1. In Windows 7 (I think it started with Vista), Microsoft locked down the ability for executables to write into system directories like C:\Windows, C:\Program Files, etc., unless they run as admin. This is probably a good thing.
  2. However, backward compatibility tells us that there are plenty of programs that want to store settings or write files into their installation directory, which is most likely located in C:\Program Files (x86)
  3. To avert this issue, Microsoft created the Virtual Store directory, which is located in C:\Users\myuser\AppData\Local\VirtualStore\ which the system uses for write access to restricted directories by overlaying it into system calls. For instance, let's say a copy of XP's HyperTerminal is installed on Windows 7 x64 into C:\Program Files (x86)\HyperTerminal\ with an HT session file called mysession.ht residing in the same directory, with this session file having been previously created and installed into C:\Program Files (x86)\HyperTerminal\ as admin. Having been developed up to XP (and yanked on later versions - more about this later), HyperTerminal saw no qualms about updating session files that reside in C:\Program Files (x86)\HyperTerminal\. And HyperTerminal needs to update your session file, whenever you exit the program, to update the terminal buffer log and other things, so it needs to write the session file every time it is used. What transparently happens the first time HT tries to update the session file is:
    1. An exact duplicate of mysession.ht is created as C:\Users\myuser\AppData\Local\VirtualStore\Program Files (x86)\HyperTerminal\mysession.ht, to which "myuser" has R/W access.
    2. On subsequent access from HT, this is the file that is being read and written, the original file from C:\Program Files (x86)\HyperTerminal\mysession.ht being left completely untouched from how it was when first copied there.
    In essence this means that there exists differing duplicates of the same file on your system, which, if you are using programs that have not been updated for Win7/Vista, is something you want to be aware of. For instance, in case you spent a lot of time creating conf/settings files in an application, and thought that a backup of the C:\Program Files (x86)\Some App\ would be enough, you might want to reconsider. This can be quite important if you want to back up application settings (IDA Pro comes to mind) as any app that was designed to store data in C:\Program Files\ will effectively store it in the Virtual Store, and simply backing up the app dir won't be enough.
  4. What does the above has to do with HyperTerminal then? Well, HyperTerminal was yanked from Vista and Win7, which is bad news if you're working with embedded devices, and say, want to transfer data using a serial console through X/Y/Zmodem... The thing is, the HyperTerminal files from XP work just fine on Win7 (even on Win7 64 bit), but they have a few limitations:
    • if you place your HT session file into a different directory than the one where HT is installed, you will have trouble opening it through a shortcut, and will get prompted about creating or opening a session file every time you run HT. Of course, this constant nagging about creating session files gets old really fast.
    • you cannot change the default startup directory to something you have R/W access to without HT getting into other issues.
    • if you receive data through X\Y\Zmodem and didn't change the directory, it'll end up in the Virtual Store by default, which is why you might want to know where exactly that directory is located.
As a bonus, if you have an XP machine available, here are the files you want to copy to reinstate HyperTerminal in Windows Vista/7:
  • C:\Program Files\Windows NT\hypertrm.exe
  • C:\Program Files\Windows NT\htrn_jis.dll
  • C:\Windows\System32\hypertrm.dll
  • C:\Windows\System32\hticons.dll
Copy all those into  C:\Program Files (x86)\HyperTerminal\ and you should be good. And yes, one could solve the Virtual Store problem by installing all these files somewhere other than Program Files, but some people might want to keep their system organized.

2010-12-04

Where does Windows device enumeration actually begin?

That's in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum.

i.e., the PCI\ USB\ HID\ branches of a Device Instance ID path all originate from ControlSet\Enum.

2010-12-02

That darn "libtoolize: AC_CONFIG_MACRO_DIR([m4]) conflicts with ACLOCAL_AMFLAGS=-I m4" error

Is caused by using CRLFs in Makefile.am. "m4<CR>" != "m4" and thus the libtoolize script will produce an error.

If you're using git, I strongly advise adding a .gitattributes file with the following:
*.sh     -crlf
*.ac     -crlf
*.am     -crlf

2010-08-31

Finally *REAL* eSATA

A.k.a. eSATAp.

What kind of moronic committee, who's mysteriously silent on eSATAp (when others have to step in and fix failures behind your back, yes, you do deserve epithets) designs a connector for external HDDs, as well as other external devices, that does not provide Power by default, especially after USB has been doing it for years.
Probably too little, too late. Still, I'd rather have eSATAp with a $15 bracket & cable, than USB 3.0 for external HDDs. When transferring data, the most straightforward solution is always the best.

2010-08-13

Schematics for a PIC 18F2550 based USB demo board


Click on the image above for the PDF schematic for a Microchip PIC 18F2550 based USB demo board, with a TTL serial port (also in .ai format).

Or, since I'm reusing their design and also have been using one of their cheap PICKit2 Kit board, I'll mention that you can also buy a more elaborate ready to assemble version of the above demo board from fun4diy.com, that doubles as a PICKit2. Note however that if you use that PICKit2 "Kit" and want serial I/O, you'll have to modify the board a little (but you can use the unused U4 pins for that).

If you're testing USB, such a demo board is very convenient to have, and most of the PIC 18F4550 firmwares you'll see can be easily ported to 16F2550. I'll try to post more about that when I get a chance.

2010-07-14

Installing MinGW-w32 on a Windows system

Edit: As of 2011, the information below should only apply if for whatever reason, you cannot use <code>mingw-get</code> for your installation needs. If you are looking for a quick and easy way to install MinGW, you should use <code>mingw-get</code>, either in its GUI version or its command line version.

This is pretty much a reformatting of this post by Xiaofan for the purpose of building libusb and similar projects
  1. Install 7-zip from http://www.7-zip.org as all the MSYS/MinGW are provided in LZMA format. Make sure you go to Options -> System and set the .lzma file association.
  2. Chose a SourceForge mirror from this list and make sure you bypass SourceForge super annoying interface, by browsing project directories in an FTP like fashion. For instance, you can use http://ftp.heanet.ie/mirrors/sourceforge/m/project/mi/mingw to get access to the files fast.
  3. Create both an msys and MinGW directories, on one of your disks, preferably at the root level. For instance, if you install to C, you should create C:\MinGW and C:\msys
  4. In the following list items, I will list the current directory you should download the files from at the root level, and the files to download at the item level. With regards to the extraction, you should extract the files into the same directory as the root for the download (eg. MinGW/BaseSystem/GCC/Version4/gcc-4.5.0-1/gcc-core-4.5.0-1 -> C:\MinGW). Note that the archives are an lzma of a tar, so in 7-zip, you should double click until you see the directories like bin/, include/ etc. These are the directories that need to be copied over to the MinGW or msys dir, so make sure you extract at the right level.
  5. MinGW/BaseSystem/GCC/Version4/gcc-4.5.0-1/
    • gcc-core-4.5.0-1-mingw32-bin.tar.lzma 
    • gcc-c++-4.5.0-1-mingw32-bin.tar.lzma 
    • libgcc-4.5.0-1-mingw32-dll-1.tar.lzma
    • libstdc++-4.5.0-1-mingw32-dll-6.tar.lzma
    • libssp-4.5.0-1-mingw32-dll-0.tar.lzma
  6. MinGW/BaseSystem/GNU-Binutils/binutils-2.20.51/
    • binutils-2.20.51-1-mingw32-bin.tar.lzma
  7. MinGW/gmp/gmp-5.0.1-1/
    • libgmp-5.0.1-1-mingw32-dll-10.tar.lzma
  8. MinGW/mpc/mpc-0.8.1-1/
    • libmpc-0.8.1-1-mingw32-dll-2.tar.lzma
  9. MinGW/mpfr/mpfr-2.4.1-1/
    • libmpfr-2.4.1-1-mingw32-dll-1.tar.lzma
  10. MinGW/BaseSystem/RuntimeLibrary/MinGW-RT/mingwrt-3.18/
    • mingwrt-3.18-mingw32-dll.tar.gz
    • mingwrt-3.18-mingw32-dev.tar.gz
  11. MinGW/BaseSystem/RuntimeLibrary/Win32-API/w32api-3.14/
    • w32api-3.14-mingw32-dev.tar.gz
  12. MSYS/BaseSystem/msys-1.0.15-1/
    • msysCORE-1.0.15-1-msys-1.0.15-bin.tar.lzma
    • msysCORE-1.0.15-1-msys-1.0.15-ext.tar.lzma (this is the file containing the postinstall script we need to run) 
  13. MSYS/autoconf/autoconf-2.65-1/
    • autoconf-2.65-1-msys-1.0.13-bin.tar.lzma
  14. MSYS/autogen/autogen-5.10.1-1/
    • autogen-5.10.1-1-msys-1.0.15-bin.tar.lzma
    • libopts-5.10.1-1-msys-1.0.15-dll-25.tar.lzma
  15. MSYS/automake/automake-1.11.1-1/
    • automake-1.11.1-1-msys-1.0.13-bin.tar.lzma
  16. MSYS/bash/bash-3.1.17-3/
    • bash-3.1.17-3-msys-1.0.13-bin.tar.lzma
  17. MSYS/console/console-2.00b146-1/
    • console-2.00b146-1-msys-1.0.14-bin.tar.lzma
  18. MSYS/coreutils/coreutils-5.97-3/
    • coreutils-5.97-3-msys-1.0.13-bin.tar.lzma
    • coreutils-5.97-3-msys-1.0.13-ext.tar.lzma
  19. MSYS/crypt/crypt-1.1_1-3/
    • libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma
  20. MSYS/gawk/gawk-3.1.7-2/
    • gawk-3.1.7-2-msys-1.0.13-bin.tar.lzma
  21. MSYS/gdbm/gdbm-1.8.3-3/
    • libgdbm-1.8.3-3-msys-1.0.13-dll-3.tar.lzma
  22. MSYS/gettext/gettext-0.17-2/
    • gettext-0.17-2-msys-1.0.13-bin.tar.lzma
    • libasprintf-0.17-2-msys-dll-0.tar.lzma
    • libgettextpo-0.17-2-msys-dll-0.tar.lzma
    • libintl-0.17-2-msys-dll-8.tar.lzma
  23. MSYS/grep/grep-2.5.4-2/
    • grep-2.5.4-2-msys-1.0.13-bin.tar.lzma
  24. MSYS/libiconv/libiconv-1.13.1-2/
    • libcharset-1.13.1-2-msys-1.0.13-dll-1.tar.lzma
    • libiconv-1.13.1-2-msys-1.0.13-dll-2.tar.lzma
  25. MSYS/libtool/libtool-2.2.7a-2/
    • libtool-2.2.7a-2-msys-1.0.13-bin.tar.lzma
    • libltdl-2.2.7a-2-msys-1.0.13-dll-7.tar.lzma
  26. MSYS/m4/m4-1.4.14-1/
    • m4-1.4.14-1-msys-1.0.13-bin.tar.lzma
  27. MSYS/make/make-3.81-3/
    • make-3.81-3-msys-1.0.13-bin.tar.lzma
  28. MSYS/patch/patch-2.6.1-1/
    • patch-2.6.1-1-msys-1.0.13-bin.tar.lzma
  29. MSYS/perl/perl-5.6.1_2-2/
    • perl-5.6.1_2-2-msys-1.0.13-bin.tar.lzma
  30. MSYS/sed/sed-4.2.1-2/
    • sed-4.2.1-2-msys-1.0.13-bin.tar.lzma
  31. MSYS/tar/tar-1.23-1/
    • tar-1.23-1-msys-1.0.13-bin.tar.lzma
  32. MSYS/termcap/termcap-0.20050421_1-2/
    • libtermcap-0.20050421_1-2-msys-1.0.13-dll-0.tar.lzma
    • termcap-0.20050421_1-2-msys-1.0.13-bin.tar.lzma
  33. MSYS/zlib/zlib-1.2.3-2/
    • zlib-1.2.3-2-msys-1.0.13-dll.tar.lzma
  34. MSYS/cvs/cvs-1.12.13-2/
    • cvs-1.12.13-2-msys-1.0.13-bin.tar.lzma
  35. MSYS/file/file-5.04-1/
    • file-5.04-1-msys-1.0.13-bin.tar.lzma
    • libmagic-5.04-1-msys-1.0.13-dll-1.tar.lzma
  36. MSYS/gzip/gzip-1.3.12-2/
    • gzip-1.3.12-2-msys-1.0.13-bin.tar.lzma
  37. MSYS/regex/regex-1.20090805-2/
    • libregex-1.20090805-2-msys-1.0.13-dll-1.tar.lzma
  38. double click msys.bat
  39. navigate to c/msys/postinstall
  40. run ./pi.sh and follow the prompts

2010-07-11

Compiling MinGW-w64 with multilib on Linux

In this post, I'll describe how to manually get a version of MinGW-w64 that (should) supports multilib (i.e. -m32 & -m64, to produce either 32 or 64 bit Windows binaries), as well as static and shared library generation on a Linux host platform, using the current latest official versions of everything. Most of what I'm going to describe is based on the mingw-w64-howto-build guides that one can find here, with fixes added. This guide is intended to be fairly generic, so that you can use it as a base for more specific settings.

Disclaimer

First of all, a bit of a warning. If you have anything urgent coming up, if your boss wants something else done by tomorrow or if you have a wife & kids requiring your attention, do not start building a cross compiler manually! You should only ever do so if you can totally waste a couple of days trying to figure out how to fix that £$%^& non working cross compilation process. As you will see soon enough, gcc is a pretty wild beast when it comes to cross compilation, and no matter what you do or which guide you follow, you're pretty much guaranteed that it's going to be anything but a smooth ride. If you don't have time to waste, there are scripts here and there that should take care of taming the beast for you. Of course, these scripts won't usually let you pick up the very latest versions, as we are going to do here, but you can't have it all. Also, of course, I make no guarantee whatsoever that what I'm describing below will actually work for you. You have been warned!


Downloads & Prerequisites

As you should know, there's a bit more to compiling MinGW than just picking up the latest MinGW and gcc. You also need binutils and gcc also relies on a few libraries, so below is the list of everything you'll need, with the latest versions available at the time of this post (2010.07.10):
All of the above are the current very latest official versions.

You will also need some disk space (preferably on a fast "disk" device) in the range of 2 to 3 GB for the whole compilation process. Better create a working directory and download everything here. Everything apart from MinGW itself can be gotten using wget or your preferred method of download, so you should go ahead and pick a copy of everything from the list above. For MinGW, just fire up the following to retrieve the source:
svn co https://mingw-w64.svn.sourceforge.net/svnroot/mingw-w64 mingw-w64
Another prerequisite that you shouldn't overlook is, since the compilation process is fraught with disappointments and restarts, the fastest and the more cores your CPU is/has, the better. Better try that process on the fastest Linux machine you can get your hands on first, and once you're satisfied that your compilation should work, do it on a slower machine if that's your final target.
For the record, I used a quad core Slackware 13.0 64 bit Linux server, which I'm hoping should be generic enough to have this guide apply to other Linux flavours.

File extraction and directory settings

If you haven't done so by now, you should extract all the tar archives downloaded above into your working directory. Now, a lot of guides will have you go through gmp+mpfr+mpc installation before you can fiddle with gcc, but that's really pointless. The newer gcc sources are designed to pick up and compile gmp, mpfr and mpc if they are available in the gcc source directory. Moreover, I have had trouble getting gcc 4.5.0 recognize the very new mpfr 3.0.0 when compiled as standalone, whereas it doesn't seem to have a problem picking it up from its source directory.
Therefore, here's what you should do once you have extracted everything:
mv mpfr-3.0.0/ gcc-4.5.0/mpfr
mv gmp-4.3.2/ gcc-4.5.0/gmp
mv mpc-0.8.2/ gcc-4.5.0/mpc
Once this is done, this is the content you should have in your working directory:
binutils-2.20.1/  binutils-2.20.1.tar.bz2  gcc-4.5.0/  gcc-4.5.0.tar.bz2  gmp-5.0.1.tar.bz2  mingw-w64/  mpc-0.8.2.tar.gz  mpfr-3.0.0.tar.bz2

Generalities

For most of the configuration, we will use the defaults, therefore, the binaries and includes will use /usr/local as their base (specific MinGW-w64 subdirectories will be created, don't worry). The only option I'm going to consistently add when running the versions configure is the --disable-nls to try to speed up things a little bit by disabling non Western language support.
Also, you should never compile any part of a cross compiler from within the extracted source directory. If you do, the whole process is bound to fail. Instead, we will create external build directories (eg. binutils-build) in our working space for each source we need to go through.
Also, since I am lucky enough to run on a quad core, I'm going to use the parallel processing option of make (-j) to considerably speed up the whole compilation process. The rule of thumb is to use j# with # being the number of cores you have at your disposal (altough I've also seen people doubling that number). Hence, almost every make command we call below will be affixed with -j4.
Oh yeah, and some people will advise to add a --build=<build-machine-triplet> all over the place, but most of the scripts we use are smart enough to detect cross compilation, so this is not necessary. You might see some warnings about --build not being specified, but you shouldn't worry too much about them.
Finally, gcc compilation is a bit unpredictable, especially if you use -j on make (but even without, weird things happen), so if your make process generates an error for any reason, the first thing to try is make again, to see if things get further. Even without -j, it sometimes takes 2 or 3 passes to get a specific section of the compilation working.

Binutils

And now the fun begins. Didn't encounter much of any issues with binutils, so the process goes as follows:
mkdir binutils-build; cd binutils-build
../binutils-2.20.1/configure --disable-nls --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32
make -j4
make install
In the above, the --target indicates that we ultimately want to produce a MinGW compiler that can produce x86_64 binaries (i.e. MinGW-w64), and the --enable-targets with 2 parameters is for multilib support, with 64 (x86_64) and 32 (i686) bit.The end result of all this is that you should get a bunch of x86_64-w64-mingw32 binaries into /usr/local/bin (ar, ld, etc)

MinGW headers

Pay attention here:  This is the headers install => the configure we run is NOT the one from trunk/ but the one from trunk/mingw-w64-headers/. If you try to run the configure from trunk/ at this stage, of course it will fail.
cd ..; mkdir mingw-build; cd mingw-build
../mingw-w64/trunk/mingw-w64-headers/configure --host=x86_64-w64-mingw32
make install
This should copy the MinGW headers into /usr/local/x86_64-w64-mingw32/include/.

MinGW directories and symlinks

With the above steps, you should end up with a /usr/local/x86_64-w64-mingw32/ directory that also contains a lib/ directory (which will be used for the 64 bit version of the libraries). If that's not the case you should create it. Now, for multilib, we'll also need a lib32/ directory, and some parts of MinGW expect a few specific directories, like lib64/ or /usr/local/mingw, so we create all that:
ln -s /usr/local/x86_64-w64-mingw32 /usr/local/mingw
mkdir -p /usr/local/x86_64-w64-mingw32/lib32
ln -s /usr/local/x86_64-w64-mingw32/lib /usr/local/x86_64-w64-mingw32/lib64

Gcc, pass 1

Now things start to get real (and problems start to appear if you don't use the right configure options):
cd ..; mkdir gcc-build; cd gcc-build
../gcc-4.5.0/configure --disable-nls --target=x86_64-w64-mingw32 --enable-languages=c,c++ --with-system-zlib --enable-multilib --enable-version-specific-runtime-libs --enable-shared --enable-fully-dynamic-string
OK, a little clarification about our configure options:
  • --enable-languages=c,c++, because, who the hell compiles 64 bit Windows binaries in Fortran or Ada, and your time is precious (plus, I think the Fortran/Ada source generate some errors). C and C++ are all you need.
  • --with-system-zlib, at least on Slackware, you do want to use that option to avoid an uncorrectable "Link tests are not allowed after GCC_NO_EXECUTABLES" error in the zlib/ directory provided by gcc. And I'm at loss to figure out why gcc does include the sources for zlib in their archive, but not the ones for gmp, mpc, mpfr, as it'd make life a lot easier for everybody.
  • --enable-version-specific-runtime-libs, --enable-fully-dynamic-string, because some people use these and say they are useful.
    [UPDATE: 2010.09.09] According to the MinGW-w64 developers, you should NOT use --enable-version-specific-runtime-libs, as this causes issues. There is currently a long discussion on the MinGW-w64 mailing list about this. Make sure you read it! I may update this guide at some stage
  • --enable-multilib, to have -m32 and -m64 support!
  • --enable-shared, to be able to compile DLLs as well as static libraries.
make all-gcc -j4
Yay, our first compilation error (sadly, won't be the last!). The above fails on
checking for gmp internal files... configure: error: header files gmp-impl.h and longlong.h not found
make: *** [configure-mpfr] Error 1
To fix that error:
cp ../gcc-4.5.0/gmp/gmp-impl.h gmp; cp ../gcc-4.5.0/gmp/longlong.h gmp
After that, the process should complete successfully with:
make all-gcc -j4
make install-gcc
Note that if you get other errors during the build (eg. "Link tests are not allowed after GCC_NO_EXECUTABLES"), just try without -j a couple of times to see if this is really a permanent error, or just gcc screwing with your nerves.

Crt (MinGW-w64)

Nothing fancy here. If you use the latest from svn, things should compile pretty nicely with:
cd ../mingw-build
../mingw-w64/trunk/configure --disable-nls --host=x86_64-w64-mingw32 --enable-lib32
make -j4
make install -j4
I think --enable-lib32 is superfluous, as recent MinGW-w64 seem to be hardwired for multilib by default. Just make sure that 32 and 64 bit are enabled on the configure summary screen.

Gcc, pass 2

"It's right when you start seeing the light at the end of the tunnel, that the arch collapses."

Thought you were out of the woods? Think again:
cd ../gcc-build
make -j4
will choke on:
/usr/local/x86_64-w64-mingw32/bin/ld: skipping incompatible /usr/local/x86_64-w64-mingw32/lib/libmingw32.a when searching for -lmingw32
and a whole bunch of similar errors. Obviously, since we're in gcc-build/x86_64-w64-mingw32/32/libgcc/ when that happens, ld should be looking in lib32/ rather than lib/.
Now, there's probably a smarter approach, but the easiest way I found to fix this is to:
  1. edit <your_working_dir>/gcc-build/x86_64-w64-mingw32/32/libgcc/Makefile
  2. copy the CC line into a CC32 line and replace all the /lib by /lib32
  3. replace GCC_FOR_TARGET = $(CC) with GCC_FOR_TARGET = $(CC32)
Note that just editing the CC line doesn't work (which I guess is due to libtool use)! You need to create a new CC32 variable.
make -j4
You might get a "Link tests are not allowed after GCC_NO_EXECUTABLES" (what the heck does that error actually mean anyway?). If that happens, just retry... until it breaks again with the "skipping incompatible when searching for -lmingw32" error again in <your_working_dir>/gcc-build/x86_64-w64-mingw32/32/libssp/
Same trick as above applies, with editing the Makefile, only this time you can edit the CC and CPP variables directly and just replace /lib with /lib32 again.
make -j4
Yup, choked again, this time in <your_working_dir>/gcc-build/x86_64-w64-mingw32/libstdc++-v3/libsupc++/, with:
/bin/sh: ../libtool: No such file or directory
Easiest solution I found:
cp ./x86_64-w64-mingw32/libssp/libtool ./x86_64-w64-mingw32/libstdc++-v3
Then once more:
make -j4
Might get a few errors, that go away on retry, and then:
../../../../gcc-4.5.0/libstdc++-v3/src/atomic.cc:26:21: fatal error: gstdint.h: No such file or directory
Easy to fix:
ln -s /usr/local/mingw/include/stdint.h /usr/local/mingw/include/gstdint.h
make -j4
...and then again:
make[6]: Entering directory `/mnt/hd/src/clean/gcc-build/x86_64-w64-mingw32/32/libstdc++-v3'
make[6]: *** No rule to make target `all'.  Stop.
Well, no surprise: there's no makefile in <your_working_dir>/gcc-build/x86_64-w64-mingw32/32/libstdc++-v3/! How I fixed it?
rm -r x86_64-w64-mingw32/32/libstdc++-v3
ln -s x86_64-w64-mingw32/libstdc++-v3/32 x86_64-w64-mingw32/32/libstdc++-v3
make -j4
...and once more, plenty of errors in ./x86_64-w64-mingw32/32/libssp/ about lib vs lib32. At least we can't say gcc compilation isn't keeping us entertained. This time, we can edit ./x86_64-w64-mingw32/32/libssp/libtool and do a search for -m32. For each line that has -m32, just replace /lib with /lib32.
$ make -j4
YAY!!! Completion at last! Just one final thing to do:
make install -j4
If you managed to make it through that last ordeal, you should now have a fully working MinGW-w64 gcc compiler, capable of producing 32 and 64 bit windows binaries, as well as static or dynamic (DLL) libraries, and using nothing but the latest versions of all the tools. Pretty cool huh?
To compile, just remember to add a --host=x86_64-w64-mingw32 when running configure, and possibly export a CFLAGS=-m32 if you want to produce 32 bit binaries.

2010-06-14

error LNK2005: strncmp already defined in LIBCMT.lib(strncmp.obj)

You're trying to mix "Multi-threaded (/MT)" with "Multi-threaded DLL (/MD)". Enough said.

2010-06-07

Preventing USB devices with different serials to be seen as separate devices

Once again, I have to give props to Xiaofan:

The following is quoted from a USB-IF forum post (the link is now invalid)
http://www.usb.org/phpbb/viewtopic.php?p=33850

"Win2000/XP has a way to ignore the serial number.
This is copied form an AppNote I wrote:
-------------------------------------------------------
Ignore serial number in Win2000 / XP In Windows 2000 and XP,
there is a way to ignore the serial number for a certain device.
This is not recommended in general, but there are reasons to do so.

This is the registry key
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags]
The global way: The entry below does enable the serial numbers despite
its name! It is already there after a fresh installation.
GlobalDisableSerNumGen = 1
We recommend keeping the above setting unchanged.

Now here is the individual way. Create an entry under the
above ...\UsbFlags key. The name must start with "IgnoreHWSerNum"
followed by the vendor and product ID of the device. The value for the
entry is 1 for disable.
Example:
IgnoreHWSerNum0536016A= 1
Our vendor ID (VID) is 0536 (hex), the product ID (PID) depends
on the interface you choose.

2010-06-03

Showing hidden devices on Windows

Courtesy of the good people of the libusb-devel mailing list:
  1. Set a System (not user) environment variable called:
    DevMgr_Show_NonPresent_Devices with value 1
  2. Tell device mgr (thru menus) to show hidden devices
See http://www.ftdichip.com/Documents/AppNotes/AN_107_AdvancedDriverOptions_AN_000073.pdf

This trick seems to work fine on Windows 7 as well.

2010-05-24

Compiling resource files with Visual Studio Express

If you pick a Visual Studio project with an MFC GUI app, and try to compile it with Visual Studio Express, you should run into the error:
fatal error RC1050: Cannot open include file 'afxres.h'.
The solution? Replace your:
#include "afxres.h"
from your .rc file with the following:
#include <windows.h>
#define IDC_STATIC -1

2010-05-14

running XP inside qemu on Windows

  • Compiled qemu from source using MinGW32/Msys (hint: add the "target-list=i386-softmmu" so that you only compile the target of interest to you). Haven't figured out how to get a Ctrl-Alt-2 that actually works yet...
  • Installed UltraVNC
  • Copied the qemu exec from i386-softmmu to pc-bios and ran everything from pc-bios
  • Created HDD image (with qemu-img)
  • Default of qemu on IPV6 system is to use IPV6 which makes the VNC connection unavailable - need to provide IPv4 address to -vnc option, and thus, from the pc-bios directory:
    qemu -usb -vnc 127.0.0.1:0 -hda winxp.img -m 512 -localtime -net user -net nic,model=rtl8139  -cdrom //./d:
  • Connected through UltraVNC viewer with "localhost::5900" and installed XP
  • First thing to do once XP is installed is to disable mouse acceleration by disabling "Enhance Pointer Precision" in Mouse Properties -> Pointer Options