Put a real CMake project in here.
This commit is contained in:
1 parent
bee2afe62b
commit
ebe5f95a3e
4 files changed
+66
-29
No files matched your search
@@ -0,0 +1,62 @@
|
||||
cmake_minimum_required(VERSION 3.4)
|
||||
project(2ine)
|
||||
|
||||
# Note that this project doesn't work on Mac OS X because I can't mmap()
|
||||
# address 0x10000, which is the usual base address for OS/2 binaries.
|
||||
# It appears the address is already accessible when main() begins, but no
|
||||
# objects seem to be loaded there. I don't know what it is...maybe some
|
||||
# thing allocated by the C runtime at startup? Have to solve that somehow or
|
||||
# give up on Mac support.
|
||||
#
|
||||
# Eventually, even on Linux, it might make sense to override malloc and friends
|
||||
# at the dynamic loader level, so we control all allocations even if they
|
||||
# happen in glibc. Once we have that, make sure they all sit in the upper
|
||||
# 2 gigabytes (reserved for system use on OS/2, so this works out), probably
|
||||
# with them mmap()'d there via a local copy of dlmalloc or something.
|
||||
#
|
||||
# Note that 32-bit OS/2 programs only got 512 megabytes of the address space
|
||||
# (enormous in the days of machines with a couple megabytes of physical RAM!)
|
||||
# to accomodate thunking to and from 16 bit code. We don't bother with this
|
||||
# at the moment, though, but maybe we must at some point. I hope not.
|
||||
#
|
||||
# Also, it might be nice if we can run as a 64-bit process and thunk around in
|
||||
# 32-bits as necessary, but I don't know the technical barriers to this yet.
|
||||
# If we can pull that off, it would allow an OS/2 app to have the full 4
|
||||
# gigabytes of memory, and we'll just put 2ine's data outside of that range,
|
||||
# and run the native bits with more registers, etc. Maybe even keep the
|
||||
# native functions out of low memory and only eat a few bytes of it with
|
||||
# trampolines. I'm probably getting ahead of myself, though, as it's not like
|
||||
# any OS/2 apps were _that_ memory hungry, and honestly? Port your software.
|
||||
|
||||
if(NOT CMAKE_BUILD_TYPE)
|
||||
set(DEBUG_BUILD ON)
|
||||
endif()
|
||||
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
|
||||
set(DEBUG_BUILD ON)
|
||||
endif()
|
||||
|
||||
if(DEBUG_BUILD)
|
||||
add_definitions(-DDEBUG -O0)
|
||||
else()
|
||||
add_definitions(-D_RELEASE)
|
||||
add_definitions(-DNDEBUG)
|
||||
add_definitions(-DRELEASE)
|
||||
endif()
|
||||
|
||||
add_definitions(-std=c99 -Wall -ggdb3)
|
||||
|
||||
foreach(_I doscalls;msg;nls;quecalls;viocalls;kbdcalls;sesmgr)
|
||||
add_library(${_I} SHARED "native/${_I}.c")
|
||||
set_target_properties(${_I} PROPERTIES COMPILE_FLAGS "-m32")
|
||||
set_target_properties(${_I} PROPERTIES LINK_FLAGS "-m32 -ggdb3")
|
||||
endforeach()
|
||||
|
||||
add_executable(lx_dump lx_dump.c)
|
||||
|
||||
add_executable(lx_loader lx_loader.c)
|
||||
target_link_libraries(lx_loader "dl")
|
||||
set_target_properties(lx_loader PROPERTIES COMPILE_FLAGS "-m32")
|
||||
set_target_properties(lx_loader PROPERTIES LINK_FLAGS "-m32 -ggdb3")
|
||||
|
||||
# end of CMakeLists.txt ...
|
||||
|
||||
+1
-1
@@ -1055,7 +1055,7 @@ static LxModule *loadLxModuleByModuleNameInternal(const char *modname, const int
|
||||
snprintf(fname, sizeof (fname), "%s.dll", modname);
|
||||
LxModule *retval = loadLxModuleByPathInternal(fname, dependency_tree_depth);
|
||||
if (!retval) {
|
||||
snprintf(fname, sizeof (fname), "native/%s.so", modname);
|
||||
snprintf(fname, sizeof (fname), "./lib%s.so", modname);
|
||||
for (char *ptr = fname; *ptr; ptr++) {
|
||||
*ptr = (((*ptr >= 'A') && (*ptr <= 'Z')) ? (*ptr - ('A' - 'a')) : *ptr);
|
||||
} // for
|
||||
|
||||
@@ -1,28 +0,0 @@
|
||||
#!/bin/sh
|
||||
|
||||
# Note that this doesn't work on Mac OS X because I can't mmap()
|
||||
# address 0x10000, which is the usual base address for OS/2 binaries.
|
||||
# It appears the address is already accessible when main() begins, but no
|
||||
# objects seem to be loaded there. I don't know what it is...maybe some
|
||||
# thing allocated by the C runtime at startup? Have to solve that somehow or
|
||||
# give up on Mac support.
|
||||
#
|
||||
# 32-bit Linux totally lets me have that space, though. :)
|
||||
#clang -pagezero_size 0x1000 -image_base 0x100000000 -Wall -O0 -ggdb3 -o lx_loader lx_loader.c && ./lx_loader ./cmd.exe
|
||||
|
||||
set -x
|
||||
set -e
|
||||
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,msg.so -o native/msg.so native/msg.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,doscalls.so.so -o native/doscalls.so native/doscalls.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,nls.so -o native/nls.so native/nls.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,quecalls.so -o native/quecalls.so native/quecalls.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,viocalls.so -o native/viocalls.so native/viocalls.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,kdbcalls.so -o native/kbdcalls.so native/kbdcalls.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -fPIC -shared -Wl,-soname,sesmgr.so -o native/sesmgr.so native/sesmgr.c
|
||||
|
||||
gcc -std=c99 -Wall -O0 -ggdb3 -o lx_dump lx_dump.c
|
||||
gcc -m32 -std=c99 -Wall -O0 -ggdb3 -o lx_loader lx_loader.c -ldl
|
||||
#./lx_dump tests/hello.exe
|
||||
./lx_loader tests/helloc.exe
|
||||
|
||||
Reference in new issue
Block a user