I had just posted a bug in the tracker when I noticed the last active bug was from '06. So I thought I'd post it here too. It actually posted in the tracker twice because I had hit the back button and Firefox asked if I wanted to Resend, to which I said, "Yes." Sorry.
Using DevIL v1.7.7 in MSVC8 here.
ilGetInteger(IL_NUM_MIPMAPS) was always reporting only one mipmap. The reason is that line 320 in ilu_mipmap.c has each new mipmap being assigned to CurMipMap->Next, where, I believe it should be CurMipMap->Mipmaps. 'Next' is being used this way all over the place in this file. Looking at il_states.c, line 629, you can see that the mipmap lineage is expected to be in the 'Mipmaps' pointer. Now, really, I think the for loop could be modified to say "SubImage = SubImage->Next" and that would fix the problem. But, that would break the pattern established with the other "SubImage" loops found in the cases above. Whether those are right or not, I don't know. This caused the DDS I was saving to only have one mipmap (the full size image, plus one mip level).
The fix I've done locally is to Find & Replace all occurrences of "->Next" with "->Mipmaps" in the ilu_mipmap.c file. It compiles and runs just fine, and it works for my purposes. But, then again, I haven't tested all of the affected functions.
Sorry, I forgot to mention that I am calling ilGetInteger(IL_NUM_MIPMAPS) after a call to iluBuildMipmaps().
Thanks, I had just replaced all instances of ->Next with ->Mipmaps just yesterday in ilu_mipmap.c due to bpoteat's post at https://sourceforge.net/forum/message.php?msg_id=6443698. I guess I just forgot to update that file when I changed how mipmaps are stored. Thanks a lot for reporting this!