Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dave Yeo

Pages: [1] 2 3 ... 200
What all is required to produce OMF from ELF? Is there a doc to read?

Here's a program that can do it, along with the documentation and source, it builds easy on OS/2, there's a copy on Hobbes.
I'm sure there is also lots of documentation out there on the OMF and the ELF formats.
As OS4User points out, another possibility is just staying with ELF until the linking stage and having a linker that can link ELF objects into LX executables and DLL's. Wlink can handle both file formats, whether it can currently build a LX executable or a DLL out of ELF obj files needs investigation. It's ELF support isn't the highest as it can't even create ELF shared libraries.
Either route needs someone who knows this stuff.

Forgive my ignorance, I'm not too familiar with this end of stuff. Without a kernel driver will things like audio, networking, graphical emulation (specifically DX-style 3d rendering), etc be a possibility? Effectively - what would the limitations/expectations be?

Basically it would have the same usability as the previous port, with hopefully the addition of working audio.
Networking would require a TAP driver I believe, which we don't have. Graphical emulation is always going to be limited due to our limited graphics drivers. Speed will be limited without a kernel driver and even with a kernel driver, the OS/2 kernel is missing stuff to take advantage of VT.
There's always the Virtual Box port for some of this stuff. It has some of the same limitations due to lack of Operating System support. Development on the OS/2 kernel basically stopped at the beginning of the century and the last things added were things like fixes for fast CPU's, along with SSEx support and the BEGINLIBPATH/LIBPATHSTRICT stuff for Mozilla development, so different DLLs with the same name could be used.
It's a 1990's operating system dragged into the 21st century.

I guess I should start by looking at ver 2.4.x (latest). I don't have the skills to write a kernel driver though, it would end being a port similar to what we have, hopefully without the SMP issues that Ivan reported.
The git repository is weird, with a whole bunch of submodules and I have no experience dealing with submodules so it seems that I can't simply check out the right tag. Git does make development easier, create a branch and commit changes.

Applications / Re: Firefox error in Addons
« on: May 06, 2021, 05:03:05 pm »
Hi Roberto.
The Sandybridge build is mostly untested, so it might be worth trying the i686 build for comparison.
The first warnings I see here when running an unpackaged freshly built Firefox, as for features folder missing crash, I haven't seen that. It is possible that your profile is corrupt, which happens.
You might also want to disable automatic updates in about:addons as we don't have access to the old compatible addons anymore due to Mozilla moving on.

Programming / Re: Updated GCC Builds
« on: May 06, 2021, 08:05:47 am »
Hi Paul,
I checked executable sizes and cc1.exe was 40+ mb so I assumed the debug symbols were there... I'll try and investigate this evening.

I assumed the same thing. Running lxlite on cc1.exe gives a 60% gain but no mention of debug data being stripped. Perhaps a -s snuck in somewhere, I hate this silent compile thing as it is too easy to miss a parameter.

General Discussion / Re: Installing eCS on a EEEPC 701 with USB
« on: May 06, 2021, 01:38:38 am »
Hi Jacopo, the problem is that after using the BIOS to boot the USB stick, eCS has no way to read the USB stick until it is installed, a chicken and egg problem.
ArcaOS gets around this by creating a ram disk and installing a minimal OS to that and then running the install from it.
As Neil said, another option is a USB DVD drive.

Programming / Re: Updated GCC Builds
« on: May 05, 2021, 04:36:08 pm »
It crashed here in,
Code: [Select]
Killed by SIGSEGV
pid=0xb561 ppid=0xb55f tid=0x0001 slot=0x00cf pri=0x0200 mc=0x0001 ps=0x0010
CC1 0:01516851
cs:eip=005b:01526851      ss:esp=0053:0300f4d0      ebp=0300f538
 ds=0053      es=0053      fs=150b      gs=0000     efl=00010202
eax=00000000 ebx=201d0100 ecx=fffdffff edx=2056900c edi=00000091 esi=20b45260
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.
gcc: internal compiler error: Segmentation fault signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <> for instructions.
make: *** [libavfilter/vf_hqx.o] Error 4

Unluckily still no debug symbols, perhaps add -Zmap and build xqs files.

Programming / Re: Updated GCC Builds
« on: May 04, 2021, 05:19:02 pm »
Tried building SeaMonkey with GCC 11.1.0, it doesn't get very far as it is not happy with the std: lib.
Code: [Select]
../dist/include/mozilla/gfx/Rect.h: In static member function 'static mozilla::gfx::RectTyped<units, F> mozilla::gfx::RectTyped<units, F>::MaxIntRect()':
../dist/include/mozilla/gfx/Rect.h:168:15: error: 'numeric_limits' is not a member of 'std'
  168 |         -std::numeric_limits<int32_t>::max() * 0.5,
      |               ^~~~~~~~~~~~~~
../dist/include/mozilla/gfx/Rect.h:168:40: error: '::max' has not been declared; did you mean 'std::max'?
  168 |         -std::numeric_limits<int32_t>::max() * 0.5,
      |                                        ^~~
      |                                        std::max

With lots more similar errors. Also see more demands for -Wclass-memaccess even though it is in the flags.

Programming / Re: Updated GCC Builds
« on: May 03, 2021, 10:58:43 pm »
Trying the opposite, building with 10.3.0 and linking with 9.9.2 results in a python error while creating the list file, whether linking with 10.3.0 or 9.9.2. Probably a problem with the fake libs.
Rather then using AR or EMXOMFAR to build static libs, the build builds libs-desc which are a list of all the object files that would have been in the static lib, it also unars some existing libs into object files then the build system gathers them all up and builds the list file. Hard to tell where the failure is happening. The build system has just got weirder and weirder as they started moving away from configure && make to a Python mess.
Here's the log.

Programming / Re: Updated GCC Builds
« on: May 03, 2021, 08:44:07 pm »
Ok, more investigation into the SM linking issue. I rebuilt with GCC 9.9.2 and then compared the linking between 9.9.2 and 10.3.0. As far as I can make out, the difference is 9.9.2 just passes the list file to the linker while 10.3.0 passes the list file and the list of obj files to the linker, which pukes on such a long command line. The list files produced by both the compilers are identical at 53777 bytes and 1204 lines (obj and lib files).
I'll attach the xul build logs from both, both done after a make clean.
edit: added list file with txt extension for completeness

Programming / Re: Updated GCC Builds
« on: May 03, 2021, 05:29:18 pm »
Yes, it looks similar. I went on to build FFmpeg with 10.3.0 so overwrote my trp.
As for SeaMonkey and 10.3.0, I found this in the log,
Code: [Select]
32:51.04 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h: In constructor 'gfxShapedWord::gfxShapedWord(const uint8_t*, uint32_t, int32_t, int32_t, uint32_t)':
32:51.04 Y:/work/cc45-git/mozilla/gfx/thebes/gfxFont.h:1277:72: warning: 'void*memset(void*, int, size_t)' clearing an object of non-trivial type 'class gfxShapedText::CompressedGlyph'; use assignment or value-initialization instead [-Wclass-memaccess]

So I added -Wclass-memaccess to CXXFLAGS (actually the optimize parameter) and that fixed the missing symbol.
Now the compile dies while linking xul.dll with a Python OSError (Errno 22), which I believe is a failure to pass the list file to emxomfld. We're linking over a 1000 object files.
Had the same or similar problem with GCC 9.2.0 and I worked around by creating my own list(response) file and manually calling emxomfld until Dmitriy fixed it sometime later.
IIRC, the problem with 9.2.0 was actually nested response files and was one of the last fixes for 9.2.0

Programming / Re: Updated GCC Builds
« on: May 03, 2021, 05:09:34 am »

I tried this, keep getting errors involving the environment. I'm not used to cmake and did try setting these environment variables

Thanks. Here's what I tried with the cc11.cmd to set CC and CXX (so cmake can find it).  This assumes the GCC 11.1 stayed in \usr\local11

Code: [Select]
set CXX=C:\usr\local11\bin\g++
set CC=C:\usr\local11\bin\gcc

cmake --debug-trycompile  ..

OK, that works fine. For 11.1.0,
Code: [Select]
[K:\work\os2\tests\cmake\_b]cmake --debug-trycompile ..
debug trycompile on
-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- Check for working C compiler: W:/usr/local11/bin/gcc.exe
-- Check for working C compiler: W:/usr/local11/bin/gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: W:/usr/local11/bin/g++.exe
-- Check for working CXX compiler: W:/usr/local11/bin/g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: K:/work/os2/tests/cmake/_b

With similar output for 10.3.0. My guess is that you didn't set up your environment correctly. Here's my gcc11env.cmd.
Code: [Select]
set PATH=W:\usr\local11\libexec\gcc\i686-pc-os2-emx\11.1.0;W:\usr\local11\bin;%PATH%
set BEGINLIBPATH=W:\usr\local11\lib;W:\usr\lib;%BEGINLIBPATH%
set C_INCLUDE_PATH=W:/usr/local11/lib/gcc/i686-pc-os2-emx/11.1.0/include;W:/usr/local11/include;W:/usr/include;%C_INCLUDE_PATH%
set CPLUS_INCLUDE_PATH=W:/usr/local11/include/c++/11.1.0;W:/usr/local11/include/c++/11.1.0/i686-pc-os2-emx;W:/usr/local11/include/c++/11.1.0/backward;W:/usr/local11/include;W:/usr/include;%CPLUS_INCLUDE_PATH%
set LIBRARY_PATH=W:/usr/local11/lib/gcc/i686-pc-os2-emx/11.1.0;W:/usr/local11/lib;W:/usr/lib;%LIBRARY_PATH%
edit, fixed gcc11env.

Programming / Re: Updated GCC Builds
« on: May 03, 2021, 05:01:09 am »
Tried building SeaMonkey with 10.3.0. made it to linking xul.dll where it died with,
Code: [Select]
82:56.24 weakld: error: Unresolved symbol (UNDEF) '__ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics'.
82:56.24 weakld: info: The symbol is referenced by:
82:56.24     Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.obj
82:56.24 Ignoring unresolved externals reported from weak prelinker.
82:56.24 Error! E2028: __ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics is an undefined reference
82:56.25 file Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.obj(Y:\work\cc45-git\obj-sm\gfx\thebes\Unified_cpp_gfx_thebes1.cpp): undefined symbol __ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics
82:56.25 make.EXE[4]: *** [xul.dll] Error 1

Gcc 9.2.0 seems to produce and link
Code: [Select]
0001:011aadb0* __ZN7gfxFont13GetShapedWordIhEEP13gfxShapedWordP10gfxContextPKT_jjibijP18gfxTextPerfMetrics$w$JhD8ijzLgS70u5P91

in both
Code: [Select]

whereas 10.3.0 only has the symbol in thebes0.obj

Programming / Re: Updated GCC Builds
« on: May 03, 2021, 04:40:29 am »
Thanks Paul.  Really cool to see a GCC 11 on here!

I grabbed the 11.1 build and tried to get it to work with cmake, and ran into an error in the "trycompile" phase where cmake introspects the compiler by building things.

Here's how to reproduce it:

Hope this helps.

I tried this, keep getting errors involving the environment. I'm not used to cmake and did try setting these environment variables
Code: [Select]
[K:\work\os2\tests\cmake\_b]cmake --debug-trycompile  ..
debug trycompile on
CMake Error at W:/usr/share/cmake/Modules/CMakeDetermineCCompiler.cmake:49 (mess
  Could not find compiler set in environment variable CC:

Call Stack (most recent call first):
  CMakeLists.txt:1 (project)

CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
CMake Error: CMAKE_CXX_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "K:/work/os2/tests/cmake/_b/CMakeFiles/CMakeOutput.log".

Programming / Re: Updated GCC Builds
« on: May 02, 2021, 07:36:43 pm »
10.3.0 succeeded at compiling FFmpeg, I'll have to double check my 11.1.0 install and retest later.

Pages: [1] 2 3 ... 200