ke2042: nasm fails to assemble files during build time

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

ke2042: nasm fails to assemble files during build time

Mateusz Viste-5
Hello group,

I am trying to compile the FreeDOS kernel from svn's tag ke2042, but it
appears that build.bat fails to assemble several files. For instance:

      nasm -DTC2 -DWITHFAT32 -i../hdr/ -DXCPU=86 -f obj floppy.asm
  nasm: error: more than one input file specified
  nasm: error: more than one input file specified

Not sure why this happens, the command looks sane. If I redo the nasm
command by hand, I get the same message. Trying to compile on DOSEMU,
using nasm v2.12.02.

Have I missed something obvious? Any clue?

regards,
Mateusz


------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Mateusz Viste-5
On Wed, 23 Nov 2016 19:25:52 +0000, Mateusz Viste wrote:
> I am trying to compile the FreeDOS kernel from svn's tag ke2042, but it
> appears that build.bat fails to assemble several files. For instance:
>
>       nasm -DTC2 -DWITHFAT32 -i../hdr/ -DXCPU=86 -f obj floppy.asm
>   nasm: error: more than one input file specified nasm: error: more than
>   one input file specified

Hi,

Your problem is related to the fact that your "nasm" command doesn't call
nasm.exe directly. Instead, it calls a batch file named nasm.bat which
has been placed in your %PATH% by the FDNPKG installer. This nasm.bat
file is pretty straight-forward:

  @ECHO OFF
  C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9

While in theory such trick should work (and it does work with most other
utilities out there), somehow it doesn't play out right with nasm. Simply
edit your CONFIG.BAT to set its XNASM variable to the full path to your
copy of nasm.exe, and you're done. Enjoy!

cheers,
Mateusz


------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

H. Peter Anvin
On 11/24/16 00:59, Mateusz Viste wrote:

>
> Hi,
>
> Your problem is related to the fact that your "nasm" command doesn't call
> nasm.exe directly. Instead, it calls a batch file named nasm.bat which
> has been placed in your %PATH% by the FDNPKG installer. This nasm.bat
> file is pretty straight-forward:
>
>   @ECHO OFF
>   C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9
>
> While in theory such trick should work (and it does work with most other
> utilities out there), somehow it doesn't play out right with nasm. Simply
> edit your CONFIG.BAT to set its XNASM variable to the full path to your
> copy of nasm.exe, and you're done. Enjoy!
>

And pray tell, why?

        -hpa



------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Travis Siegel


On 11/29/2016 3:32 PM, H. Peter Anvin wrote:

> On 11/24/16 00:59, Mateusz Viste wrote:
>> Hi,
>>
>> Your problem is related to the fact that your "nasm" command doesn't call
>> nasm.exe directly. Instead, it calls a batch file named nasm.bat which
>> has been placed in your %PATH% by the FDNPKG installer. This nasm.bat
>> file is pretty straight-forward:
>>
>>    @ECHO OFF
>>    C:\DEVEL\NASM\NASM.EXE %1 %2 %3 %4 %5 %6 %7 %8 %9
>>
>> While in theory such trick should work (and it does work with most other
>> utilities out there), somehow it doesn't play out right with nasm. Simply
>> edit your CONFIG.BAT to set its XNASM variable to the full path to your
>> copy of nasm.exe, and you're done. Enjoy!
>>
> And pray tell, why?
>
> -hpa
>
>
>
Because, apparently the nasm being called isn't in c:\devel\nasm, so
change the path in the nasm.bat file to point to the proper place, and
the problem should be solved.  Either solution will work.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

H. Peter Anvin
On 11/29/16 12:50, Travis Siegel wrote:
>
> Because, apparently the nasm being called isn't in c:\devel\nasm, so
> change the path in the nasm.bat file to point to the proper place, and
> the problem should be solved.  Either solution will work.
>

But why the batch file in the first place?  It truly makes no sense: it
pollutes the namespace equally, and can just cause problems (e.g. in the
case of more than 9 arguments.)  Not to mention slowing down a make.

        -hpa



------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Mateusz Viste-5
On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
> But why the batch file in the first place?  It truly makes no sense: it
> pollutes the namespace equally, and can just cause problems (e.g. in the
> case of more than 9 arguments.)  Not to mention slowing down a make.

Here's the thing: I, as a user, store lots of useful software on my PC.
Many of these programs are so useful that I like to have them available
immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.

To achieve this, I know of four ways. Each comes with some limitations.

Method 1: Store every program in its own directory, and add each
directory to the %PATH%. Problem: obviously the environment will get very
bloated, very fast. Besides, some programs come with add-on tools that I
do not want to be available from within my path.

Method 2: Trim out the programs from everything besides a single exe, and
put them all in a single directory declared in my %PATH%. But this poses
two problems that I cannot live with: first, not every program can be
trimmed out to a single executable file (data files, config files, etc),
and second - almost all programs come with their respective README files
and other valuable documentation that I really want to keep within the
vicinity of the executable (ie. in the same directory).

Method 3: Store each tool in its own directory, and place a COPY of its
executable inside a directory in the %PATH%. Well, this is just messy -
upgrading the program needs to think about replacing the executable each
time in both places, and it's simply a waste of disk space.

Method 4: Keep each program in its own directory with all its original
files, and only store *.bat "links" in a single directory somewhere in
the PATH. This mitigates the troubles of methods 1 and 2, at the cost,
unfortunately, of *.bat's own limitations (max 9 args and '=' processing
weirdness).

The method 4 is what I started doing back in the nineties, and as of
today I still didn't find a better (or let's say, less worse) way. That's
a lifetime project it would seem.

The method 4 is also something that I implemented last year inside FDNPKG
(the FreeDOS package manager), but since I discovered recently how oddly
the '=' character is processed in %1-like arguments (there's a separate
thread about that on freedos-devel), I will have to figure out some
improved method... first thought pointed to computing some COM loader
relying on INT21,4Bh but that's far less trivial than the current batch
method, and hobby time is scarce.

Mateusz


------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Louis Santillan
Method 1 is the traditional DOS way of installing software.

Maybe some advanced usage of JOIN & SUBST is what you are looking for?

Another alternative (though slightly messy) would be to combine
Methods 1 & 4.  By that, I mean, leave the *.bats in C:\DOS.  The
*.bats will temporarily create a new Environment & PATH extended as
the application expects and then remove the adjustment.  This will
slow down many types of computing, as HPA mentioned, SW builds come to
mind

-L.

On Tue, Nov 29, 2016 at 2:54 PM, Mateusz Viste <[hidden email]> wrote:

> On Tue, 29 Nov 2016 13:02:59 -0800, H. Peter Anvin wrote:
>> But why the batch file in the first place?  It truly makes no sense: it
>> pollutes the namespace equally, and can just cause problems (e.g. in the
>> case of more than 9 arguments.)  Not to mention slowing down a make.
>
> Here's the thing: I, as a user, store lots of useful software on my PC.
> Many of these programs are so useful that I like to have them available
> immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
> QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
>
> To achieve this, I know of four ways. Each comes with some limitations.
>
> Method 1: Store every program in its own directory, and add each
> directory to the %PATH%. Problem: obviously the environment will get very
> bloated, very fast. Besides, some programs come with add-on tools that I
> do not want to be available from within my path.
>
> Method 2: Trim out the programs from everything besides a single exe, and
> put them all in a single directory declared in my %PATH%. But this poses
> two problems that I cannot live with: first, not every program can be
> trimmed out to a single executable file (data files, config files, etc),
> and second - almost all programs come with their respective README files
> and other valuable documentation that I really want to keep within the
> vicinity of the executable (ie. in the same directory).
>
> Method 3: Store each tool in its own directory, and place a COPY of its
> executable inside a directory in the %PATH%. Well, this is just messy -
> upgrading the program needs to think about replacing the executable each
> time in both places, and it's simply a waste of disk space.
>
> Method 4: Keep each program in its own directory with all its original
> files, and only store *.bat "links" in a single directory somewhere in
> the PATH. This mitigates the troubles of methods 1 and 2, at the cost,
> unfortunately, of *.bat's own limitations (max 9 args and '=' processing
> weirdness).
>
> The method 4 is what I started doing back in the nineties, and as of
> today I still didn't find a better (or let's say, less worse) way. That's
> a lifetime project it would seem.
>
> The method 4 is also something that I implemented last year inside FDNPKG
> (the FreeDOS package manager), but since I discovered recently how oddly
> the '=' character is processed in %1-like arguments (there's a separate
> thread about that on freedos-devel), I will have to figure out some
> improved method... first thought pointed to computing some COM loader
> relying on INT21,4Bh but that's far less trivial than the current batch
> method, and hobby time is scarce.
>
> Mateusz
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Freedos-kernel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freedos-kernel

------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Jason Hood
In reply to this post by Mateusz Viste-5
On 30/11/2016 8:54, Mateusz Viste wrote:
> Here's the thing: I, as a user, store lots of useful software on my PC.
> Many of these programs are so useful that I like to have them available
> immediately from anywhere: ZIP, UNZIP, UNRAR, UPX, NASM, TCC, OPTIPNG,
> QV, MPXPLAY, UHEX, GOPHERUS, LAME... the list goes on and on.
>
> To achieve this, I know of four ways. Each comes with some limitations.

Simtel had two programs that create links: exelink2.zip and linkln10.zip.
I though I had the former, but apparently no longer; iirc it used a text
file to store the links and a TSR to hook the EXEC call.

--
Jason.

------------------------------------------------------------------------------
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Robert Riebisch
Hi Jason,

>> To achieve this, I know of four ways. Each comes with some limitations.
>
> Simtel had two programs that create links: exelink2.zip and linkln10.zip.
> I though I had the former, but apparently no longer; iirc it used a text
> file to store the links and a TSR to hook the EXEC call.

I have used http://www.bttr-software.de/freesoft/menu.htm#linkln for
many years.

Robert Riebisch
--
              +++ BTTR Software +++
     Home page:  http://www.bttr-software.de/
DOS ain't dead:  http://www.bttr-software.de/forum/

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: ke2042: nasm fails to assemble files during build time

Jason Hood
On 6/12/2016 7:23, Robert Riebisch wrote:
> I have used http://www.bttr-software.de/freesoft/menu.htm#linkln for
> many years.

Yeah, that sounds like the one I was thinking of (and the Free
Software list is probably where I came across it).  I don't think
I ever used it (stopped using DOS around that time), just curious
to how it worked.

--
Jason.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Freedos-kernel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Loading...