|
osdir.com mailing list archive |
|
Subject: Re: [Nasm-bugs] [ nasm-Bugs-2005428 ] %imacro case-sensitivity - msg#00087List: lang.nasm.develDreamWalker wrote: > I redownloaded the source and just compiled it without making any > changes whatsoever, and I ran into the exact same problems with the new > executable (which is attached to this email). I modified the makefile to > output the results to a file, and this is what it came up with: > preproc.c(670) : warning C4047: '=' : 'MMacro *' differs in levels of > indirection from 'int' > preproc.c(4146) : warning C4047: '=' : 'MMacro *' differs in levels of > indirection from 'int' > preproc.c(4242) : warning C4047: '=' : 'MMacro *' differs in levels of > indirection from 'int' > preproc.c(4264) : warning C4047: '=' : 'MMacro *' differs in levels of > indirection from 'int' > preproc.c(4280) : warning C4047: '=' : 'MMacro *' differs in levels of > indirection from 'int' However, I did try building on MSVC++ 2005, and it does indeed exhibit this problem. I thought it might have been related to the signedness problems in 2.03.01, but top of tree behaves the same way. *Dig dig dig*... it looks like nasm_stricmp() and nasm_strnicmp() are broken, which explains why the djgpp and mingw-generated binaries don't fail: they use str[n]casecmp() from the platform. I just checked in a fix for this; it should be in tomorrow's snapshot (20080629). > I am thinking that since the binaries work, but the new binaries after > compilation doesn't work, the problem may be with the compiler itself. > Can you reinclude the DJGPP makefile, or is DJGPP not supported anymore? > I thought about using the binaries if for some reason I can not make a > working executable, but for the life of me I can't find where I read a > long time ago that there was a switch to purge all of defines, macros, > etc, prior to including new header files that would have caused a clash > if the original macros were not purged. DJGPP is supported (and is what we use to generate the DOS binaries); since make, (ba)sh and coreutils are available for the DJGPP environment, it can be used with the standard configure script. For what it's worth, the compiler we use to generate the Win32 binaries is MinGW, http://www.mingw.org/. -hpa ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php Thread at a glance:
Previous Message by Date: click to view message previewRe: My involvement and the future of NASMH. Peter Anvin wrote: > > As I've already expressed, it feels the less useful direction to me. > NASM being LGPL, or even the original license, hasn't kept someone from > making a behind-lock-and-key derivative, but it's not possible to > distribute a version of NASM which deals with NDA material. My first > preference would be to do to a more liberal license. > > Going to GPL would have the main advantage that we could use the libbfd > backends. That's a massive task in its own right, though. > By the way, I don't have any intent of changing anything unilaterally, but I think this is worth a discussion. I think LGPL was a poor choice of license, picked mostly based on ability to reach consensus than anything else. -hpa ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php Next Message by Date: click to view message previewRe: My involvement and the future of NASMH. Peter Anvin wrote: > H. Peter Anvin wrote: >> >> As I've already expressed, it feels the less useful direction to me. >> NASM being LGPL, or even the original license, hasn't kept someone >> from making a behind-lock-and-key derivative, but it's not possible >> to distribute a version of NASM which deals with NDA material. My >> first preference would be to do to a more liberal license. >> >> Going to GPL would have the main advantage that we could use the >> libbfd backends. That's a massive task in its own right, though. >> > > By the way, I don't have any intent of changing anything unilaterally, > but I think this is worth a discussion. I think LGPL was a poor > choice of license, picked mostly based on ability to reach consensus > than anything else. Agreed. The BSD license would have made much more sense and would have made things much less restrictive. > > -hpa > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php Previous Message by Thread: click to view message previewRe: [Nasm-cvs] AES instructions are WESTMERE, not NEHALEMPCLMUL is WESTMERE too. Also, MOVBE is ATOM, and VF* are post-SANDYBRIDGE (i.e. a not-yet- confirmed codename -- if you know what to search for, it already shows up though). ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php Next Message by Thread: click to view message previewMere Lurking EndsThough I am working on a publication in C, NASM has been my favorite tool, since I have yet to find a decent, 32-bit debug.exe, and POSIX+UNIX+Linux+GNU-coreinetutils are way more fun than DOS. I hope to eventually be able to submit a rewrite of NASM in NASM for my 16-bit XT with FreeDOS and my 32-bit P-III with Linux with a 1600x1200, 32bit frame-buffer and my 64-bit AMD with XP with Cygwin with X or Linux with X, in one self-contained file with the file headers and enough of the standard C library. However, if something is not written in C, it just isn't portable enough to invest enough time into maintaining it. I can still use the source code for the standard library for the single, 360K floppy machine as a good starting point for floating-point with a machine with an optional FPU. I just got side-tracked trying to figure out how to write the little, "This program is not for DOS" script in the 32-bit mode of NASM for the 16-bit mode of the O/S. ;Without making it too easy, we could arrive at something near... .16bit call .1 + 90h*65536 + 90h*256*65536 db "This program does nops in sixteen bits..." .1 pop edx; ndisasm -b16 will translate edx to dx; inc edx inc edx mov ah, 9 int 21h mov ah, 4Ch int 21h I don't have any way of knowing what license would be the best for such a thing, but everything that the developers of NASM have done has been really good for aspiring developer-hobbyists such as myself. I really appreciate it, and I am going to do as much as I can toward keeping the dust knocked off of your beautiful sources. It would be cool to have all kinds of additional things in the contributed, non-maintained part. NAGOA.inc of the RADIDE or whatever (RASN?) and the whirlwind tutorial on the tiny ELF or maybe a whole bunch of snippets... HRM. K. I gotta go. I just wanted to have my name in here with the greats. Thank you! jonathan_david_conrad.vcf Description: Vcard ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php_______________________________________________ Nasm-devel mailing list Nasm-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/nasm-devel Loading Comments...
|
|
