DOS ain't dead

Got a query for those whom are well-versed in DJGPP.

How long should it take to build mplayer.exe
using the source code provided by Khusraw back in 2012 ?

My i7 machine is booted to OpenDos7.01,
everything is on a FAT16 partition, doslfn.com is loaded.

My 1st attempt to build mplayer.exe stopped at looking for WATT32

Got WATT32 source in-place and the next attempt stopped looking for
the freetype fonts needed for the subtitles etc.

Got the freetype font in-place,
the current attempt has now been running continuously
(as is indicated by the constant flickering of the HDD light), for over 46hrs

No change on-screen because I'm using STDERR.EXE to redirect
all screen output into a text file to examine later for any errors.

http://glennmcc.dynu.com/my-stuff/images/DJGPP.jpg

---
--
http://glennmcc.org/

> Got a query for those whom are well-versed in DJGPP.
>
> How long should it take to build mplayer.exe
> using the source code provided by Khusraw back in 2012 ?
>
> My i7 machine is booted to OpenDos7.01,
> everything is on a FAT16 partition, doslfn.com is loaded.
>
> My 1st attempt to build mplayer.exe stopped at looking for WATT32
>
> Got WATT32 source in-place and the next attempt stopped looking for
> the freetype fonts needed for the subtitles etc.
>
> Got the freetype font in-place,
> the current attempt has now been running continuously
> (as is indicated by the constant flickering of the HDD light), for over
> 46hrs
>
> No change on-screen because I'm using STDERR.EXE to redirect
> all screen output into a text file to examine later for any errors.
>
> http://glennmcc.dynu.com/my-stuff/images/DJGPP.jpg

Something seems very wrong if the compile is taking 46 hours on an i7. I would think an i7 could compile that code in 4.6 minutes, or at most 46 minutes. Unless you're compiling to something very, very slow like a USB memory stick and / or with very poor read / write speeds, I'd say you are stuck in some kind of loop.

This is why I don't like to compile sourcecode, but so much prefer it when people provide their own binaries of their code! Unless you're going to be modifying the code extensively, at the very least the author would do all a great favor by compiling the vanilla sourcecode for us. I know Khusraw did provide us binaries, so I'm not singling him out. But, many times it's hard to impossible for end users to compile source code correctly, and / or takes an enormous amount of work and a huge toolchain to get it compiled, especially in operating systems like DOS. There's a lot of great stuff posted on github, but I've tried and failed more often than not to get code to compile, and just thrown in the towel, wishing beyond all, that authors had provided pre-compiled binaries of their posted code.

> > Got a query for those whom are well-versed in DJGPP.
> >
> > How long should it take to build mplayer.exe
> > using the source code provided by Khusraw back in 2012 ?
> >
> > My i7 machine is booted to OpenDos7.01,
> > everything is on a FAT16 partition, doslfn.com is loaded.
> >
> > My 1st attempt to build mplayer.exe stopped at looking for WATT32
> >
> > Got WATT32 source in-place and the next attempt stopped looking for
> > the freetype fonts needed for the subtitles etc.
> >
> > Got the freetype font in-place,
> > the current attempt has now been running continuously
> > (as is indicated by the constant flickering of the HDD light), for over
> > 46hrs
> >
> > No change on-screen because I'm using STDERR.EXE to redirect
> > all screen output into a text file to examine later for any errors.
> >
> > http://glennmcc.dynu.com/my-stuff/images/DJGPP.jpg
>
> Something seems very wrong if the compile is taking 46 hours on an i7. I
> would think an i7 could compile that code in 4.6 minutes, or at most 46
> minutes. Unless you're compiling to something very, very slow like a USB
> memory stick and / or with very poor read / write speeds, I'd say you are
> stuck in some kind of loop.

Nope... no USB memory stick... FAT16 HDD

Well... it has now been 48hrs and 10min
So, I'll now stop it and check the TXT file for errors.

>
> This is why I don't like to compile sourcecode, but so much prefer it when
> people provide their own binaries of their code! Unless you're going to be
> modifying the code extensively, at the very least the author would do all a
> great favor by compiling the vanilla sourcecode for us. I know Khusraw did
> provide us binaries, so I'm not singling him out. But, many times it's hard
> to impossible for end users to compile source code correctly, and / or
> takes an enormous amount of work and a huge toolchain to get it compiled,
> especially in operating systems like DOS. There's a lot of great stuff
> posted on github, but I've tried and failed more often than not to get code
> to compile, and just thrown in the towel, wishing beyond all, that authors
> had provided pre-compiled binaries of their posted code.

As to code modifications.... Yep, that is my plan.

But first I wanted to compile the code as-is before making any changes.

---
--
http://glennmcc.org/

>
> Well... it has now been 48hrs and 10min
> So, I'll now stop it and check the TXT file for errors.
>

No errors of any kind shown.

Will now try without the use of STDERR.EXE just in case it was causing problems.

---
--
http://glennmcc.org/

> >
> > Well... it has now been 48hrs and 10min
> > So, I'll now stop it and check the TXT file for errors.
> >
>
> No errors of any kind shown.
>
> Will now try without the use of STDERR.EXE just in case it was causing
> problems.

OK... got much furer this time and hit a major error.

http://glennmcc.dynu.com/my-stuff/images/static_follows_non-static.jpg

---
--
http://glennmcc.org/

> > >
> > > Well... it has now been 48hrs and 10min
> > > So, I'll now stop it and check the TXT file for errors.
> > >
> >
> > No errors of any kind shown.
> >
> > Will now try without the use of STDERR.EXE just in case it was causing
> > problems.
>
> OK... got much furer this time and hit a major error.
>
> http://glennmcc.dynu.com/my-stuff/images/static_follows_non-static.jpg

Why not try compiling w/Windows 95 or 98?

I compiled my FFMPEG for DOS build under WinXP SP3 that works much fasterrr than DOS with DOSLFN and if I remember it took about 5-10 minutes on my i7 so Mplayer should not be much more complex to take magnitudes longer...

---
DOS gives me freedom to unlimited HW access.

> > > >
> > > > Well... it has now been 48hrs and 10min
> > > > So, I'll now stop it and check the TXT file for errors.
> > > >
> > >
> > > No errors of any kind shown.
> > >
> > > Will now try without the use of STDERR.EXE just in case it was causing
> > > problems.
> >
> > OK... got much furer this time and hit a major error.
> >
> > http://glennmcc.dynu.com/my-stuff/images/static_follows_non-static.jpg
>
> Why not try compiling w/Windows 95 or 98?

Ain't got 'em.

I completely rid my systems of MS quite a few years ago.

My systems have _only_ OpenDos 7.01 & Slackware64-current

---
--
http://glennmcc.org/

> I compiled my FFMPEG for DOS build under WinXP SP3 that works much fasterrr
> than DOS with DOSLFN and if I remember it took about 5-10 minutes on my i7
> so Mplayer should not be much more complex to take magnitudes longer...

I don't have anything MS here... _only_ OpenDos 7.01 & Slackware64-current

Another query....

Has anyone else here attempted to compile mplayer.exe for DOS
using DJGPP & this source code provided by Khusraw
which was used for his DOS build in 2012 ?

http://glennmcc.dynu.com/download/mplayer_khusraw/mplayer_source_khusraw_2012.7z

---
--
http://glennmcc.org/

Hello glennmcc, hello Oso2k,

> > Why not try compiling w/Windows 95 or 98?
> Ain't got 'em.
> I completely rid my systems of MS quite a few years ago.

There is probably no need to use Win95 or Win98. From the looks of it, the compilation process was actualy working — there were just some issues that with the mplayer source code that caused it to conflict with DJGPP's C header files.

More precisely, the mplayer source code was — for some reason — defining functions trunc(.) and truncf(.), but the C library had already defined these, and so there was a conflict.

(Perhaps the mplayer code decided to define these functions because it erroneously thought that they were not defined? Newer versions of the mplayer source code might have resolved this problem some way or other.)

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> Hello glennmcc, hello Oso2k,
>
> > > Why not try compiling w/Windows 95 or 98?
> > Ain't got 'em.
> > I completely rid my systems of MS quite a few years ago.
>
> There is probably no need to use Win95 or Win98. From the looks of it, the
> compilation process was actualy working — there were just some issues
> that with the mplayer source code that caused it to conflict with DJGPP's C
> header files.
>
> More precisely, the mplayer source code was — for some reason —
> defining functions trunc(.) and truncf(.), but the C library had already
> defined these, and so there was a conflict.
>
> (Perhaps the mplayer code decided to define these functions because it
> erroneously thought that they were not defined? Newer versions of the
> mplayer source code might have resolved this problem some way or other.)
>
> Thank you!



Ahh. My only point in suggesting Win9x was that if it was slow disk access causing delay, then Win9x & XP tend to have better file system access code.

Another thing to try would be Andrew Wu’s djgpp on Linux cross compilers. You might even be able to use parallel build flags.

Or, run djgpp on Linux with DOSBox.

>
> Ahh. My only point in suggesting Win9x was that if it was slow disk access
> causing delay, then Win9x & XP tend to have better file system access code.
>
>
> Another thing to try would be
> Andrew Wu’s djgpp on
> Linux cross compilers. You might even be able to use parallel build
> flags.
>
> Or, run djgpp on Linux with DOSBox.

Thanks to everyone who offered various suggestions.

However, that 1st major error which was a redefinition of 'truncf'
in libm.h from Khusraw's mplayer source code versus the original
definition in djgpp's math.h turned-out to be just one of many, many
incompatibilities.

When I corrected that one by editing libm.h to match 'truncf' in math.h
anther incompatibility would crop-up... fix that one and another would crop-up
etc...etc...

So, it seems to me that when Khusraw compiled mplayer.exe in 2012
that compile must have using some 'custom' libraries rather than the 'stock'
libraries included in djgpp.

If that assumption is correct... this mplayer source code is not going
to compile without having those 'custom' libraries.

---
--
http://glennmcc.org/

Hello glennmcc,

I see that the mplayer source code you linked to includes `configure' scripts (`threads/src/configure', `mplayer/ffmpeg/configure', `mplayer/configure').

Did you at least try to run `./configure' in `mplayer/', before running `make', when you first tried to build the program?

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> So, it seems to me that when Khusraw compiled mplayer.exe in 2012
> that compile must have using some 'custom' libraries rather than the
> 'stock'
> libraries included in djgpp.
>
> If that assumption is correct... this mplayer source code is not going
> to compile without having those 'custom' libraries.

No, I didn't use any 'custom' library, have you run configure with the correct argument (the argument required for DJGPP)?

---
Glory to God for all things

> > So, it seems to me that when Khusraw compiled mplayer.exe in 2012
> > that compile must have using some 'custom' libraries rather than the
> > 'stock'
> > libraries included in djgpp.
> >
> > If that assumption is correct... this mplayer source code is not going
> > to compile without having those 'custom' libraries.
>
> No, I didn't use any 'custom' library, have you run configure with the
> correct argument?

Ah ha... no, I did not.

Sorry for being such an inept newbie to DJGPP :(

I now have bash.exe and will run the configure script.

Khusraw...

Might you be able to provide a link to your mplayer && ffmpeg
source code used for the compile you made in 2017 ?

Thank you.

---
--
http://glennmcc.org/

> Might you be able to provide a link to your mplayer && ffmpeg
> source code used for the compile you made in 2017 ?

You probably take me for someone else, you have my latest source code (from 2012, I didn't make a more recent compile).

---
Glory to God for all things

> > Might you be able to provide a link to your mplayer && ffmpeg
> > source code used for the compile you made in 2017 ?
>
> You probably take me for someone else, you have my latest source code (from
> 2012, I didn't make a more recent compile).

I misunderstood this one as being built by you.

http://www.bttr-software.de/forum/forum_entry.php?id=18256

---
--
http://glennmcc.org/

I never compiled mplayer.

---
DOS gives me freedom to unlimited HW access.

I was in touch with Michael Kostylev in 2017 helping with testing of new build but I didn't see sources of it.
BTW it would be good to always include exact configure script options list to be able to reproduce the build or maybe preconfigured sources. This is not specific to DJGPP but for all project using configure script. I rather like projects that use Makefile only but it's still better to work with configure than with cmake/automake/etc under DOS...

---
DOS gives me freedom to unlimited HW access.

> I was in touch with Michael Kostylev in 2017 helping with testing of new
> build but I didn't see sources of it.
> BTW it would be good to always include exact configure script options list
> to be able to reproduce the build or maybe preconfigured sources. This is
> not specific to DJGPP but for all project using configure script. I rather
> like projects that use Makefile only but it's still better to work with
> configure than with cmake/automake/etc under DOS...

Well, I have come to the conclusion that this just is _not_
going to work using this 'environment' so-to-speak.

1) booted to OpenDos v7.01
2) using doslfn.com to provide LFN sopport
3) everything located on a FAT16 partition
___________________________________________________

What setup (OS, file system, etc),
is best for using DJGPP to build DOS programs ?
____________________________________________________

Khusraw,

What OS did you boot into to build mplayer.exe for DOS ?

---
--
http://glennmcc.org/

> Khusraw,
>
> What OS did you boot into to build mplayer.exe for DOS ?

Windows XP.

---
Glory to God for all things

> > Khusraw,
> >
> > What OS did you boot into to build mplayer.exe for DOS ?
>
> Windows XP.

Alright.....
dug through my 'junk drawer' and now have WinXP installed on an old 80 gig HDD

---
--
http://glennmcc.org/

> > > Khusraw,
> > >
> > > What OS did you boot into to build mplayer.exe for DOS ?
> >
> > Windows XP.
>
> Alright.....
> dug through my 'junk drawer' and now have WinXP installed on an old 80 gig
> HDD

There... ran into the same situation as before....

In mplayer/ffmpeg/libavutil/libm.h


http://glennmcc.dynu.com/my-stuff/images/static_follows_non-static.jpg

error: static declaration of 'trunc' (and several more), follows non-static declaration

The previous declaration is as extern in c:\djgpp\include\math.h


Checked Linux and in /usr/include/math.h _None_ of those items are in there
like they are in c:\djgpp\include\math.h

---
--
http://glennmcc.org/

Well.... what the heck does _this_ indicate as being the problem ???

BTW,

All of these attempts to build mplayer.exe are using Khusraw's
configuration files which were included in the source .7z archive.


GNU Make 4.3 (DJGPP port (r1))
Built for i786-pc-msdosdjgpp
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Reading makefile 'config.mak' (search path) (no ~ expansion)...

<clipped most for brevity>


Prerequisite 'ffmpeg/libavutil//x86/x86util.asm' is older than target 'ffmpeg/libavutil/libavutil.a'.
Prerequisite 'config.h' is older than target 'ffmpeg/libavutil/libavutil.a'.
Prerequisite 'help_mp.h' is older than target 'ffmpeg/libavutil/libavutil.a'.
Prerequisite 'help_mp.h' is older than target 'ffmpeg/libavutil/libavutil.a'.
No need to remake target 'ffmpeg/libavutil/libavutil.a'.
Finished prerequisites of target file 'mplayer.exe'.
Must remake target 'mplayer.exe'.
gcc -o mplayer.exe command.o m_property.o mixer.o mp_fifo.o mplayer.o

<clipped most for brevity>

-lgthreads -static -lvbe -lx264 -lm -lgthreads
ld: cannot find -lwatt
ld: cannot find -liconv
ld: cannot find -lpng
ld: cannot find -lz
ld: cannot find -lmng
ld: cannot find -ljpeg
ld: cannot find -lz
ld: cannot find -ljpeg
ld: cannot find -lopenjpeg
ld: cannot find -lwss
ld: cannot find -lfreetype
ld: cannot find -lz
ld: cannot find -ltheoradec
ld: cannot find -logg
ld: cannot find -lxvidcore
ld: cannot find -lgthreads
ld: cannot find -lvpx
ld: cannot find -lgthreads
ld: cannot find -lvbe
ld: cannot find -lx264
ld: cannot find -lgthreads
collect2.exe: error: ld returned 1 exit status
Putting child 4b83d0 (mplayer.exe) PID 123 on the chain.
Live child 4b83d0 (mplayer.exe) PID 123
Reaping losing child 4b83d0 PID 123
make: *** [Makefile:795: mplayer.exe] Error 1
Removing child 4b83d0 PID 123 from chain.

---
--
http://glennmcc.org/

I don't wonder about header/libs mess thats sooo typical to build anything larger...

But I also remember one mission critical thing to sucessfully compile FFMPEG: I need to manually increase transfer buffer size for some DJGPP compiler components: make.exe, ar.exe a rm.exe
stubedit.exe program.exe bufsize=xxk

E:\DJGPP\BIN>STUBEDIT.EXE -v AR.EXE
-value- -field description-
0x80000 (512k) Minimum amount of stack space (bytes/K/M)
0x8000 (32k) Size of real-memory transfer buffer (bytes/K/M)
"" Base name of file to actually run (max 8 chars, ""=self)
"" Value to pass as file component of argv[0] (max 16 chars, ""=default)

And also other binutils had issues with max relocations

https://groups.google.com/g/comp.os.msdos.djgpp/c/LRjb_i-Cb_w

No, life's not easy I don't wonder that anyone else don't compile mplayer for DOS...

---
DOS gives me freedom to unlimited HW access.

> All of these attempts to build mplayer.exe are using Khusraw's
> configuration files which were included in the source .7z archive.

Again, have you run before in bash "configure MS-DOS" or whatever the option for creating the DJGPP specific makefiles?

---
Glory to God for all things

> > All of these attempts to build mplayer.exe are using Khusraw's
> > configuration files which were included in the source .7z archive.
>
> Again, have you run before in bash "configure MS-DOS" or whatever the
> option for creating the DJGPP specific makefiles?

I am attempting to build using _your_ configuration as included in the .7z

Be that as it may... I did run bash ./configure
and it failed to detect my CPU and OS but rather simply used 'UNKNOWN'
for both and would not create the new config.h & config.mak

---
--
http://glennmcc.org/

> > > All of these attempts to build mplayer.exe are using Khusraw's
> > > configuration files which were included in the source .7z archive.
> >
> > Again, have you run before in bash "configure MS-DOS" or whatever the
> > option for creating the DJGPP specific makefiles?
>
> I am attempting to build using _your_ configuration as included in the .7z
>
> Be that as it may... I did run bash ./configure
> and it failed to detect my CPU and OS but rather simply used 'UNKNOWN'
> for both and would not create the new config.h & config.mak


http://glennmcc.dynu.com/my-stuff/Khusraw-mplayer-config.txt

With all of those config* & Makefile in-place

cd into mplayer_source_khusraw_2012/mplayer/ and type 'make'

Shouldn't that result in a fresh compile of mplayer.exe & mencoder.exe
the same as yours from Jan 2012 ?

---
--
http://glennmcc.org/

> I am attempting to build using _your_ configuration as included in the .7z

Which "my" configuration?! I only made a few modifications to MPlayer's configure script in order to enable optional DJGPP compile.

> Be that as it may... I did run bash ./configure
> and it failed to detect my CPU and OS but rather simply used 'UNKNOWN'
> for both and would not create the new config.h & config.mak

It's the last time when I tell you that you have to run "configure MS-DOS" or whatever the option for creating the DJGPP specific makefiles, just look on the script. If you run configure without any option you certainly won't get what you want.

---
Glory to God for all things

> > I am attempting to build using _your_ configuration as included in the
> .7z
>
> Which "my" configuration?! I only made a few modifications to MPlayer's
> configure script in order to enable optional DJGPP compile.
>
> > Be that as it may... I did run bash ./configure
> > and it failed to detect my CPU and OS but rather simply used 'UNKNOWN'
> > for both and would not create the new config.h & config.mak
>
> It's the last time when I tell you that you have to run "configure
> MS-DOS" or whatever the option for creating the DJGPP specific
> makefiles, just look on the script. If you run configure without any option
> you certainly won't get what you want.

All I meant by _your_ configuration, is that these Makefile(s)
along with config.h and config.mak that you used to build mplayer.exe
using DJGPP were included in the source code .7z that you made available to us.

26469 Jan 22 2012 mplayer_source_khusraw_2012/mplayer/config.mak
259631 Jan 21 2012 mplayer_source_khusraw_2012/mplayer/configure
40229 Jan 22 2012 mplayer_source_khusraw_2012/mplayer/config.h
217387 Jan 22 2012 mplayer_source_khusraw_2012/mplayer/config.log
47 Jan 21 2012 mplayer_source_khusraw_2012/mplayer/mplayer/config
531 Jan 22 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/config.asm
99 Jan 22 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/config.mak
114524 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/configure
24 Jan 22 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/config.h
1719 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/bfin/config_bfin.h


49918 Jan 23 2012 mplayer_source_khusraw_2012/mplayer/Makefile
4459 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/Makefile
143 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libpostproc/Makefile
969 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libswscale/Makefile
209 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libswresample/Makefile
8286 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavfilter/Makefile
45824 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/Makefile
5459 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavutil/Makefile
1616 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/doc/Makefile
4126 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/tests/Makefile
20459 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavformat/Makefile
1904 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavdevice/Makefile
122 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavfilter/x86/Makefile
148 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/sparc/Makefile
444 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/alpha/Makefile
222 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/sh4/Makefile
1384 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/ppc/Makefile
4805 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/arm/Makefile
4302 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/x86/Makefile
518 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/bfin/Makefile
222 Dec 25 2011 mplayer_source_khusraw_2012/mplayer/ffmpeg/libavcodec/mips/Makefile
475 Jan 4 2012 mplayer_source_khusraw_2012/mplayer/ffmpeg/doc/examples/Makefile


Perhaps I was mistaken and those are not the files which were used to build mplayer.exe on DJGPP

---
--
http://glennmcc.org/

Hello glennmcc,

> > It's the last time when I tell you that you have to run "configure
> > MS-DOS" or whatever the option for creating the DJGPP specific
> > makefiles, just look on the script. If you run configure without any
> option
> > you certainly won't get what you want.
> All I meant by _your_ configuration, is that these Makefile(s)
> along with config.h and config.mak that you used to build mplayer.exe
> using DJGPP were included in the source code .7z that you made available to
> us.

Just try following Khusraw's suggestion. This is not hard. Rerun the `./configure' script with the needed parameter, maybe

./configure MS-DOS

Here is the thing: The version of DJGPP you are using might be different from the DJGPP Khusraw was using back in 2012. (E.g. truncf(.) might have been missing back in 2012...) Rerunning the `configure' script will help to smooth over these differences and do the correct thing.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

> Hello glennmcc,
>
> > > It's the last time when I tell you that you have to run "configure
> > > MS-DOS" or whatever the option for creating the DJGPP specific
> > > makefiles, just look on the script. If you run configure without any
> > option
> > > you certainly won't get what you want.
> > All I meant by _your_ configuration, is that these Makefile(s)
> > along with config.h and config.mak that you used to build mplayer.exe
> > using DJGPP were included in the source code .7z that you made available
> to
> > us.
>
> Just try following Khusraw's suggestion. This is not hard. Rerun the
> `./configure' script with the needed parameter, maybe
>
> ./configure MS-DOS
>
> Here is the thing: The version of DJGPP you are using might be different
> from the DJGPP Khusraw was using back in 2012. (E.g. truncf(.) might have
> been missing back in 2012...) Rerunning the `configure' script will help
> to smooth over these differences and do the correct thing.
>
> Thank you!

I have indeed re-run bash ./configure with the correct options 'cus
none of the auto functions work on this setup of Opendos, FAT16, doslfn.exe

I finally got it to complete the process and it generated new
config.h & config.mak

Now to give you an idea how tremendously slow it runs.. that _should_ take just a minute of two but on this setup... 35min :(

That's why I dug through the junk drawer, found the XP install disc
and tried it all over again in XP

But.... the exact same problem cropped up with the redeclaretion of truncf
and several others vis a vi math.h / libm.h

Anyways.... I'm done wasting everyone's time here so
will now say that (for me at-least), this thread is closed.

---
--
http://glennmcc.org/

> But.... the exact same problem cropped up with the redeclaretion of truncf
> and several others vis a vi math.h / libm.h

This may be caused by changes in djgpp libc during time since 2012. In the past some funcs maybe missing so mplayer declared its own while it was added later and then conflict appear. I also have some messing with libm when I played with ffmpeg...

---
DOS gives me freedom to unlimited HW access.

> > But.... the exact same problem cropped up with the redeclaretion of
> truncf
> > and several others vis a vi math.h / libm.h
>
> This may be caused by changes in djgpp libc during time since 2012. In the
> past some funcs maybe missing so mplayer declared its own while it was
> added later and then conflict appear. I also have some messing with libm
> when I played with ffmpeg...

Ah ha.... math.h in DJGPP v2 is indeed newer (2015), than the 2012 mplayer code.

Perhaps it is necessary to get all of DJGPP from here instead ???

http://ftp.delorie.com/pub/djgpp/deleted/v1/

Yep, that might do it.

math.h in v1 is from 1994 and it does not contain trunc, truncf, etc...

---
--
http://glennmcc.org/

> Perhaps it is necessary to get all of DJGPP from here instead ???
>
> http://ftp.delorie.com/pub/djgpp/deleted/v1/
>
> Yep, that might do it.
>
> math.h in v1 is from 1994 and it does not contain trunc, truncf, etc...

You need only djdev204.zip, it's what I used.

EDIT: You can get it e.g. from www.mirrorservice.org/sites/ftp.delorie.com/pub/djgpp/deleted/beta/v2/.

---
Glory to God for all things

> > Perhaps it is necessary to get all of DJGPP from here instead ???
> >
> > http://ftp.delorie.com/pub/djgpp/deleted/v1/
> >
> > Yep, that might do it.
> >
> > math.h in v1 is from 1994 and it does not contain trunc, truncf, etc...
>
> You need only djdev204.zip, it's what I used.
>
> EDIT: You can get it e.g. from
> www.mirrorservice.org/sites/ftp.delorie.com/pub/djgpp/deleted/beta/v2/.

OK then... it looks like I need to get pretty-much
everything from the deleted/beta directories.

---
--
http://glennmcc.org/

> > > Perhaps it is necessary to get all of DJGPP from here instead ???
> > >
> > > http://ftp.delorie.com/pub/djgpp/deleted/v1/
> > >
> > > Yep, that might do it.
> > >
> > > math.h in v1 is from 1994 and it does not contain trunc, truncf,
> etc...
> >
> > You need only djdev204.zip, it's what I used.
> >
> > EDIT: You can get it e.g. from
> > www.mirrorservice.org/sites/ftp.delorie.com/pub/djgpp/deleted/beta/v2/.
>
> OK then... it looks like I need to get pretty-much
> everything from the deleted/beta directories.


I just can not win :(

Prerequisite 'config.h' is older than target 'ffmpeg/libpostproc/libpostproc.a'.
Prerequisite 'help_mp.h' is older than target 'ffmpeg/libpostproc/libpostproc.a'.
Prerequisite 'help_mp.h' is older than target 'ffmpeg/libpostproc/libpostproc.a'.
Must remake target 'ffmpeg/libpostproc/libpostproc.a'.
c:/djgpp/bin/make.exe -C ffmpeg libpostproc/libpostproc.a
GNU Make 4.3 (DJGPP port (r1))
Built for i786-pc-msdosdjgpp
Copyright (C) 1988-2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Reading makefile 'config.mak' (search path) (no ~ expansion)...
Reading makefile '../config.mak' (search path) (no ~ expansion)...
memblockpnxt: memory fouled
Exiting due to signal SIGABRT
Raised at eip=0003b3dc
eax=000d9460 ebx=00000120 ecx=00000000 edx=00000000 esi=000d9578 edi=00000000
ebp=000d9518 esp=000d9450 program=c:\djgpp\bin\make.exe
cs: sel=01ff base=02dd0000 limit=0012ffff
ds: sel=0207 base=02dd0000 limit=0012ffff
es: sel=0207 base=02dd0000 limit=0012ffff
fs: sel=01d7 base=0000c760 limit=0000ffff
gs: sel=0217 base=00000000 limit=0010ffff
ss: sel=0207 base=02dd0000 limit=0012ffff
App stack: [000daa50..0005aa50] Exceptn stack: [0005a96c..00058a2c]

Call frame traceback EIPs:
0x0003b32b
0x0003b3dc
0x0002b250
0x0002b4c2
0x00025b5e
0x00026661
0x0001a8eb
0x00009f92
0x0000afe3
0x0000b290
0x000058a7
0x00005d93
0x00005e5a
0x0002329b
0x00023b4b
0x0001b49e
0x0001d266
0x0001d569
0x000159de
0x000343e4
Putting child 3604d0 (ffmpeg/libpostproc/libpostproc.a) PID 262 on the chain.
Live child 3604d0 (ffmpeg/libpostproc/libpostproc.a) PID 262
Reaping losing child 3604d0 PID 262
make: *** [Makefile:788: ffmpeg/libpostproc/libpostproc.a] Error -1
Removing child 3604d0 PID 262 from chain.

---
--
http://glennmcc.org/

Ouch, make crashed. Did you tried to increase transferbuffer size for make.exe via stubedit as I suggested before?

---
DOS gives me freedom to unlimited HW access.

> Ouch, make crashed. Did you tried to increase transferbuffer size for
> make.exe via stubedit as I suggested before?

Have not tried it yet.

That crash happens as soon as it tries to build libpostproc in ffmpeg

I even tried doing that manually.

cd ffmpeg/libpostproc

make

CRASH !!

---
--
http://glennmcc.org/

Are you running your WXP on real HW or virtualized? How much RAM? Maybe try this particular make under DOS... But patching TB size is the fastest and harmless step to do (not sure it will help in this case).

---
DOS gives me freedom to unlimited HW access.

> Are you running your WXP on real HW or virtualized? How much RAM? Maybe try
> this particular make under DOS... But patching TB size is the fastest and
> harmless step to do (not sure it will help in this case).

Not XP anymore... booted to OpenDos v7.01

---
--
http://glennmcc.org/

> I don't wonder about header/libs mess thats sooo typical to build anything
> larger...
>
> But I also remember one mission critical thing to sucessfully compile
> FFMPEG: I need to manually increase transfer buffer size for some DJGPP
> compiler components: make.exe, ar.exe a rm.exe
> stubedit.exe program.exe bufsize=xxk
>
> E:\DJGPP\BIN>STUBEDIT.EXE -v AR.EXE
> -value- -field description-
> 0x80000 (512k) Minimum amount of stack space (bytes/K/M)
> 0x8000 (32k) Size of real-memory transfer buffer (bytes/K/M)
> "" Base name of file to actually run (max 8 chars, ""=self)
> "" Value to pass as file component of argv[0] (max 16 chars,
> ""=default)
>
> And also other binutils had issues with max relocations
>
> https://groups.google.com/g/comp.os.msdos.djgpp/c/LRjb_i-Cb_w
>
> No, life's not easy I don't wonder that anyone else don't compile mplayer
> for DOS...

Buffer is now 32K

Still crashes :(

Should the stack space also be increased ?


COMSPEC=C:\COMMAND.COM
OS=OPENDOS
VER=7
ARA=ON
TZ=+0400
PATH=H:\DJGPP\BIN;H:\DJGPP\BIN-OLD;C:\UXUTL;C:\;C:\OPENDOS
PROMPT=$d $b $t$_[OPENDOS 7.01] $P$G
TEMP=C:\TEMP
OPENDOSCFG=C:\OPENDOS
DJGPP=h:\djgpp\djgpp.env

(GO32.EXE v1 is in BIN-OLD)

stub.exe -v \djgpp\bin\make.exe
-value- -field description-
0x80000 (512k) Minimum amount of stack space (bytes/K/M)
0x8000 (32k) Size of real-memory transfer buffer (bytes/K/M)
"" Base name of file to actually run (max 8 chars, ""=self)
"" Value to pass as file component of argv[0] (max 16 chars, ""=default)
CWSDPMI.EXE Program to load to provide DPMI services (if needed)

H:\DJGPP\BUILD\MPLAYER\MPLAYER>make
Exiting due to signal SIGSEGV
Page fault at eip=0002b22e, error=0004
eax=00000001 ebx=00000030 ecx=000fec10 edx=000febe0 esi=000d9578 edi=00000000
ebp=000d9558 esp=000d9550 program=H:\DJGPP\BIN\MAKE.EXE
cs: sel=00a7 base=00400000 limit=0011ffff
ds: sel=00af base=00400000 limit=0011ffff
es: sel=00af base=00400000 limit=0011ffff
fs: sel=008f base=00018190 limit=0000ffff
gs: sel=00bf base=00000000 limit=0010ffff
ss: sel=00af base=00400000 limit=0011ffff
App stack: [000daa50..0005aa50] Exceptn stack: [0005a96c..00058a2c]

Call frame traceback EIPs:
0x0002b22e
0x0002b4c2
0x00025b5e
0x00026661
0x0001a8eb
0x00009f92
0x0000afe3
0x0000b290
0x000058a7
0x00005d93
0x00005e5a
0x0002329b
0x00023b4b
0x0001b49e
0x0001d266
0x0001d569
0x000159de
0x000343e4

---
--
http://glennmcc.org/

> > I don't wonder about header/libs mess thats sooo typical to build
> anything
> > larger...
> >
> > But I also remember one mission critical thing to sucessfully compile
> > FFMPEG: I need to manually increase transfer buffer size for some DJGPP
> > compiler components: make.exe, ar.exe a rm.exe
> > stubedit.exe program.exe bufsize=xxk
> >
> > E:\DJGPP\BIN>STUBEDIT.EXE -v AR.EXE
> > -value- -field description-
> > 0x80000 (512k) Minimum amount of stack space (bytes/K/M)
> > 0x8000 (32k) Size of real-memory transfer buffer (bytes/K/M)
> > "" Base name of file to actually run (max 8 chars,
> ""=self)
> > "" Value to pass as file component of argv[0] (max 16
> chars,
> > ""=default)
> >
> > And also other binutils had issues with max relocations
> >
> > https://groups.google.com/g/comp.os.msdos.djgpp/c/LRjb_i-Cb_w
> >
> > No, life's not easy I don't wonder that anyone else don't compile
> mplayer
> > for DOS...
>
> Buffer is now 32K
>
> Still crashes :(
>
> Should the stack space also be increased ?
>
>
> COMSPEC=C:\COMMAND.COM
> OS=OPENDOS
> VER=7
> ARA=ON
> TZ=+0400
> PATH=H:\DJGPP\BIN;H:\DJGPP\BIN-OLD;C:\UXUTL;C:\;C:\OPENDOS
> PROMPT=$d $b $t$_[OPENDOS 7.01] $P$G
> TEMP=C:\TEMP
> OPENDOSCFG=C:\OPENDOS
> DJGPP=h:\djgpp\djgpp.env
>
> (GO32.EXE v1 is in BIN-OLD)
>
> stub.exe -v \djgpp\bin\make.exe
> -value- -field description-
> 0x80000 (512k) Minimum amount of stack space (bytes/K/M)
> 0x8000 (32k) Size of real-memory transfer buffer (bytes/K/M)
> "" Base name of file to actually run (max 8 chars, ""=self)
> "" Value to pass as file component of argv[0] (max 16 chars,
> ""=default)
> CWSDPMI.EXE Program to load to provide DPMI services (if needed)
>
> H:\DJGPP\BUILD\MPLAYER\MPLAYER>make
> Exiting due to signal SIGSEGV
> Page fault at eip=0002b22e, error=0004
> eax=00000001 ebx=00000030 ecx=000fec10 edx=000febe0 esi=000d9578
> edi=00000000
> ebp=000d9558 esp=000d9550 program=H:\DJGPP\BIN\MAKE.EXE
> cs: sel=00a7 base=00400000 limit=0011ffff
> ds: sel=00af base=00400000 limit=0011ffff
> es: sel=00af base=00400000 limit=0011ffff
> fs: sel=008f base=00018190 limit=0000ffff
> gs: sel=00bf base=00000000 limit=0010ffff
> ss: sel=00af base=00400000 limit=0011ffff
> App stack: [000daa50..0005aa50] Exceptn stack: [0005a96c..00058a2c]
>
> Call frame traceback EIPs:
> 0x0002b22e
> 0x0002b4c2
> 0x00025b5e
> 0x00026661
> 0x0001a8eb
> 0x00009f92
> 0x0000afe3
> 0x0000b290
> 0x000058a7
> 0x00005d93
> 0x00005e5a
> 0x0002329b
> 0x00023b4b
> 0x0001b49e
> 0x0001d266
> 0x0001d569
> 0x000159de
> 0x000343e4
____________________________________

And now on WinXP....

ALLUSERSPROFILE=C:\Documents and Settings\All Users
APPDATA=C:\Documents and Settings\glennmcc\Application Data
CLIENTNAME=Console
CommonProgramFiles=C:\Program Files\Common Files
COMPUTERNAME=GLENNMCC-XP
ComSpec=C:\WINDOWS\system32\cmd.exe
djgpp=c:\djgpp\djgpp.env
FP_NO_HOST_CHECK=NO
HOMEDRIVE=C:
HOMEPATH=\Documents and Settings\glennmcc
LOGONSERVER=\\GLENNMCC-XP
NUMBER_OF_PROCESSORS=2
OS=Windows_NT
Path=c:\djgpp\bin;c:\djgpp\bin-old;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 11, GenuineIntel
PROCESSOR_LEVEL=6
PROCESSOR_REVISION=0f0b
ProgramFiles=C:\Program Files
PROMPT=$P$G
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\WINDOWS
TEMP=C:\DOCUME~1\glennmcc\LOCALS~1\Temp
TMP=C:\DOCUME~1\glennmcc\LOCALS~1\Temp
USERDOMAIN=GLENNMCC-XP
USERNAME=glennmcc
USERPROFILE=C:\Documents and Settings\glennmcc
windir=C:\WINDOWS
ECHO is on

stub.exe -v \djgpp\bin\make.exe
-value- -field description-
0x80000 (512k) Minimum amount of stack space (bytes/K/M)
0x8000 (32k) Size of real-memory transfer buffer (bytes/K/M)
"" Base name of file to actually run (max 8 chars, ""=self)
"" Value to pass as file component of argv[0] (max 16 chars, ""=default)
CWSDPMI.EXE Program to load to provide DPMI services (if needed)

C:\DJGPP\BUILD\MPLAYER\MPLAYER\make
memblockpnxt: memory fouled
Exiting due to signal SIGABRT
Raised at eip=0003b3dc
eax=000d9460 ebx=00000120 ecx=00000000 edx=00000000 esi=000d9578 edi=00000000
ebp=000d9518 esp=000d9450 program=c:\djgpp\bin\MAKE.EXE
cs: sel=01a7 base=02900000 limit=0010ffff
ds: sel=01af base=02900000 limit=0010ffff
es: sel=01af base=02900000 limit=0010ffff
fs: sel=017f base=00008190 limit=0000ffff
gs: sel=01bf base=00000000 limit=0010ffff
ss: sel=01af base=02900000 limit=0010ffff
App stack: [000daa50..0005aa50] Exceptn stack: [0005a96c..00058a2c]

Call frame traceback EIPs:
0x0003b32b
0x0003b3dc
0x0002b250
0x0002b4c2
0x00025b5e
0x00026661
0x0001a8eb
0x00009f92
0x0000afe3
0x0000b290
0x000058a7
0x00005d93
0x00005e5a
0x0002329b
0x00023b4b
0x0001b49e
0x0001d266
0x0001d569
0x000159de
0x000343e4


___________________________


I just can't win, so, I'm done screwing with it.

---
--
http://glennmcc.org/

An interesting saga which proves beyond all doubt that messing with source code and trying to compile it can be a Herculean task, maddening, and frustrating.

Thankfully, I had one recent very pleasant compilation task. The game Loonies 8192 had its source recently released. I used Borland C++ 3.1 for DOS, made sense of that source, needed to concatenate a few .cpp files into one and shorten some long filenames -- without using the 'required' DOSBOX, python, or LFNs, and viola, miracle of miracles, I had a working flat-16 bit C executable in about only 30 minutes of tinkering! Hoo-ray. I even modified the source to get rid of some needless bloat, reducing the compiled binary down some 4 - 5 kb over the "stock" binary.

> Buffer is now 32K
> Still crashes :(
> Should the stack space also be increased ?

I never need to change stack size.
I think it would be better to direct this question to DJGPP google group where are some ppl who better knows DJGPP internals:
https://groups.google.com/g/comp.os.msdos.djgpp

---
DOS gives me freedom to unlimited HW access.

Hi,
I just found on DJGPP group that someone else complains about Make 4.3 doesn't work as expected and he solved it reverting to Make 4.1 so maybe you could give a try...
http://groups.google.com/g/comp.os.msdos.djgpp/c/KmKoIaAzLIw

---
DOS gives me freedom to unlimited HW access.

> Hi,
> I just found on DJGPP group that someone else complains about Make 4.3
> doesn't work as expected and he solved it reverting to Make 4.1 so maybe
> you could give a try...
> http://groups.google.com/g/comp.os.msdos.djgpp/c/KmKoIaAzLIw

Fantastic.

Have now grabbed that older version of make.exe from the DJGPP site and
it now goes into the ffmpeg dir _without_ crashing.

THANK YOU !!!

---
--
http://glennmcc.org/

> > Hi,
> > I just found on DJGPP group that someone else complains about Make 4.3
> > doesn't work as expected and he solved it reverting to Make 4.1 so maybe
> > you could give a try...
> > http://groups.google.com/g/comp.os.msdos.djgpp/c/KmKoIaAzLIw
>
> Fantastic.
>
> Have now grabbed that older version of make.exe from the DJGPP site and
> it now goes into the ffmpeg dir _without_ crashing.
>
> THANK YOU !!!

Well, SHIT !!!

GNU Make 4.1 (DJGPP port (r1))
Built for i786-pc-msdosdjgpp
Copyright (C) 1988-2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Reading makefile 'Makefile'...
Reading makefile 'config.mak' (search path) (no ~ expansion)...
Reading makefile 'asxparser.d' (search path) (don't care) (no ~ expansion)...
Reading makefile 'bstr.d' (search path) (don't care) (no ~ expansion)...


<snipped most>

No implicit rule found for 'libswscale/x86/scale.asm'.
Finished prerequisites of target file 'libswscale/x86/scale.asm'.
No need to remake target 'libswscale/x86/scale.asm'.
Pruning file 'libswscale/'.
Pruning file 'libswscale/x86/'.
Finished prerequisites of target file 'libswscale/x86/scale.o'.
Must remake target 'libswscale/x86/scale.o'.
Command line too long.

Putting child 105c68 (libswscale/x86/scale.o) PID 129 on the chain.
Live child 105c68 (libswscale/x86/scale.o) PID 129
Reaping losing child 105c68 PID 129
subdir.mak:20: recipe for target 'libswscale/x86/scale.o' failed
make.exe[1]: *** [libswscale/x86/scale.o] Error -1
Removing child 105c68 PID 129 from chain.
make.exe[1]: Leaving directory 'h:/djgpp/build/mplayer/ffmpeg'
Putting child 5284f0 (ffmpeg/libswscale/libswscale.a) PID 126 on the chain.
Live child 5284f0 (ffmpeg/libswscale/libswscale.a) PID 126
Reaping losing child 5284f0 PID 126
Makefile:788: recipe for target 'ffmpeg/libswscale/libswscale.a' failed
make.exe: *** [ffmpeg/libswscale/libswscale.a] Error 2
Removing child 5284f0 PID 126 from chain.

---
--
http://glennmcc.org/

> > > Hi,
> > > I just found on DJGPP group that someone else complains about Make 4.3
> > > doesn't work as expected and he solved it reverting to Make 4.1 so
> maybe
> > > you could give a try...
> > > http://groups.google.com/g/comp.os.msdos.djgpp/c/KmKoIaAzLIw
> >
> > Fantastic.
> >
> > Have now grabbed that older version of make.exe from the DJGPP site and
> > it now goes into the ffmpeg dir _without_ crashing.
> >
> > THANK YOU !!!
>
> Well, SHIT !!!
>
> GNU Make 4.1 (DJGPP port (r1))
> Built for i786-pc-msdosdjgpp
> Copyright (C) 1988-2014 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Reading makefiles...
> Reading makefile 'Makefile'...
> Reading makefile 'config.mak' (search path) (no ~ expansion)...
> Reading makefile 'asxparser.d' (search path) (don't care) (no ~
> expansion)...
> Reading makefile 'bstr.d' (search path) (don't care) (no ~ expansion)...
>
>
> <snipped most>
>
> No implicit rule found for 'libswscale/x86/scale.asm'.
> Finished prerequisites of target file 'libswscale/x86/scale.asm'.
> No need to remake target 'libswscale/x86/scale.asm'.
> Pruning file 'libswscale/'.
> Pruning file 'libswscale/x86/'.
> Finished prerequisites of target file 'libswscale/x86/scale.o'.
> Must remake target 'libswscale/x86/scale.o'.
> Command line too long.
>
> Putting child 105c68 (libswscale/x86/scale.o) PID 129 on the chain.
> Live child 105c68 (libswscale/x86/scale.o) PID 129
> Reaping losing child 105c68 PID 129
> subdir.mak:20: recipe for target 'libswscale/x86/scale.o' failed
> make.exe[1]: *** [libswscale/x86/scale.o] Error -1
> Removing child 105c68 PID 129 from chain.
> make.exe[1]: Leaving directory 'h:/djgpp/build/mplayer/ffmpeg'
> Putting child 5284f0 (ffmpeg/libswscale/libswscale.a) PID 126 on the
> chain.
> Live child 5284f0 (ffmpeg/libswscale/libswscale.a) PID 126
> Reaping losing child 5284f0 PID 126
> Makefile:788: recipe for target 'ffmpeg/libswscale/libswscale.a' failed
> make.exe: *** [ffmpeg/libswscale/libswscale.a] Error 2
> Removing child 5284f0 PID 126 from chain.

______________


Had a feeling that the command line was _NOT_ actually too long but
rather there's something going awry in the process that caused that
message to be displayed even tho the command line was not too long.


Confirmed... the command line was _not_ too long.

Copied the entire thing over to the WinXP machine and ran make -d in the XP NTVDM

It went right on past that point, compiled libswscale/x86/scale.o
along with many, many more till it failed at _this_ point.

Prerequisite 'libavutil/avstring.h' is older than target 'libpostproc/postprocess.o'.
Prerequisite 'libpostproc/postprocess_template.c' is older than target 'libpostproc/postprocess.o'.
Prerequisite 'libavutil/x86_cpu.h' is older than target 'libpostproc/postprocess.o'.
No need to remake target 'libpostproc/postprocess.o'.
Finished prerequisites of target file 'libpostproc/libpostproc.a'.
Must remake target 'libpostproc/libpostproc.a'.
make.exe[1]: Entering directory 'c:/djgpp/build/mplayer/ffmpeg'
Putting child 324dc8 (libpostproc/libpostproc.a) PID 123 on the chain.
Live child 324dc8 (libpostproc/libpostproc.a) PID 123
Reaping losing child 324dc8 PID 123
subdir.mak:27: recipe for target 'libpostproc/libpostproc.a' failed
make.exe[1]: *** [libpostproc/libpostproc.a] Error -1
Removing child 324dc8 PID 123 from chain.
make.exe[1]: Leaving directory 'c:/djgpp/build/mplayer/ffmpeg'
Putting child 523238 (ffmpeg/libpostproc/libpostproc.a) PID 123 on the chain.
Live child 523238 (ffmpeg/libpostproc/libpostproc.a) PID 123
Reaping losing child 523238 PID 123
Makefile:788: recipe for target 'ffmpeg/libpostproc/libpostproc.a' failed
make.exe: *** [ffmpeg/libpostproc/libpostproc.a] Error 2
Removing child 523238 PID 123 from chain.
_____________________________________________________________________________

No indication as to _WHY_ it failed to build libpostproc/libpostproc.a

---
--
http://glennmcc.org/

I'm pretty-much fed up with this project and think it's time
to tackle something that should be quite a bit easier.

I'll see if I can find a bootleg copy of the SRC code for Win11
and compile it to run on a 286

---
--
http://glennmcc.org/