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/