| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
SUA linking in Visual Studio - how to?
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 SUA linking in Visual Studio - how to? - Jan. 11, '06, 9:45:46 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
I'm playing with GNU make, trying to find out how to do it in Visual Studio 2005. I'm also rather odd: I love the Windows DDK build utility. So the ultimate goal is to be able use build with interix programs. I suspect that build is the tool used by MS to manage the UNIX subsystem - or? An idea would be to implement a mixed mode version of GNU make as a Visual Studio addin.
System: Windows 2003 R2 with interix (SUA) 5.2
Visual Studio 2005, Windows DDK 2003 SP1
GNU make 3.81beta4
Compiling GNU make with gcc is straightforward:
configure, make and you're done. The binary is rather fat (466 kB) but manage to run all perl tests 100% OK - Amazing! Win32, CygWin or MinGW binaries usually fail 80% of the tests.
With cc and c89 configure fails with the message:
"checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details."
In any case, compiling GNU make with the MS compiler require source code editing. Compile with warning level 4, disable warnings 4018, 4100, 4127, 4130, 4131, 4242, 4244, 4245, 4267, 4311, 4389 and fix the rest. Use the HAVE_ANSI_COMPILER and __INTERIX conditional and evaluate all __STDC__, __GNU_LIBRARY__ and WINDOWS32 conditionals (among other things). I'm working on a bug report to the GNU make maintainers. Unfortunally, the overall support for the MS compiler in GNU make is poor and needs improvement - anyone concerned about this: Join the GNU make Win32 discussion forum.
Visual Studio 2005:
/SUBSYSTEM:POSIX /ENTRY:"__PosixProcessStartup"
_CONSOLE HAVE_CONFIG_H __INTERIX _ALL_SOURCE (_CTYPE_DISABLE_MACROS)
When everything compiles OK the main question is:
How to link with interix?
-----------------------------------------------------------
"dynamic" linking with: psxlibc.lib libpsxdll.a crtexe.o
1>commands.obj : error LNK2001: unresolved external symbol ___sF
1>commands.obj : error LNK2001: unresolved external symbol __ictype
Tried to compile with _REENTRANT and _IMPORT_LIBCDLL_GLOBALS resulting in strange compile error: "error C2059: syntax error : 'type'"
_CTYPE_DISABLE_MACROS - solves the ictype symbol.
-----------------------------------------------------------
"static" linking with: libcsafe.a libpsxdll.a safecrt0.o
1>job.obj : error LNK2001: unresolved external symbol __alloca_probe_16
1>main.obj : error LNK2001: unresolved external symbol __alloca_probe_8
I can't find any prototype for alloca, yet it is exported from libc. alloca_probe is exported from ntdll.dll but not imported by psxdll.dll.
Some other topics:
stdcall calling convention in interix?
linking with DDK libs (ie ntdll.dll - have some CRT functions)?
Tip:
A good alternative to Visual Studio 2005 is Visual Studio 6 targetting the tools, headers and libs from Windows DDK 2003 (not SP1). Compiler/linker version 13.10.2179/7.10.2179 - compatible with VS6 ide (best MS compiler ever?). Complemented with Visual Assist and Hollistech ddkbuild this is a very good tool.
best regards Jerker Bäck
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 11, '06, 10:53:18 PM
|
|
|
markfunk
Posts: 670
Joined: Mar. 31, '03,
Status: offline
|
quote:
So the ultimate goal is to be able use build with interix programs.
That would be cool. I suspect it will never (I hate using 'never') be possible, since
build.exe assumes its running in a Windows environment with Win32 tools.
If you had the source code for build.exe, we may be able to "fix" it.
The other alternative is to write wrapper scripts that look like UNIX tools, but
accepted the Win32 syntax command line arguments, converted them to UNIX syntax
and then called the real Interix program. A lot of work, for little gain.
quote:
build is the tool used by MS to manage the UNIX subsystem - or?
Originally, everything MS built used build.exe. Like the POSIX subsystem.
But once we (Softway) got Interix running with real UNIX tools, we quickly converted
all the build tools to use /bin/cc and /bin/make.
There are just some things that build.exe could not do.
And since we didn't have the source code, and since build.exe was undocumented,
we didn't really have a choice.
Nowadays, there are probably parts of the SUA subsystem that could easily
be built using build.exe, and someone may have had to figure out how to
convert the rest.
quote:
An idea would be to implement a mixed mode version of GNU make as a Visual Studio addin.
I don't think this idea would work. The problem with MS tools, is that they assume they are using Windows tools. Interix tools aren't designed to work in a
Windows environment. They're designed for a UNIX environment. Mixed mode doesn't help in this regard. Mixed mode is useful if you have UNIX source code (so you can recompile it)
and you need to access non-conflicting apis located in Win32 built DLLs.
quote:
See `config.log' for more details."
So what does the log file say ? Using cc is usually the correct approach since its written to work with VS compilers. But each VS compiler has a different tool layout, so cc has to be modified for each new version.
If you want to use GNU make in VStudio, then you want to build it as a Win32 program. Not an Interix program. Thus, you want to stick to using only Win32 libraries and DLLs. You do not want to use any of the SUA/Interix libraries.
Normally this is done using the Cygwin or Mingw build environments.
PS: The link errors you are getting are because you are trying to link Interix and Win32 DLLs that are incompatible with each other.
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 10:05:03 AM
|
|
|
jumphigh
Posts: 61
Joined: Jul. 10, '04,
From: Germany
Status: offline
|
I recommend to look inside the cc-script of SfU. There you can see how to use a MS compiler to get a POSIX exe.
Maybe things changed with SUA but on SfU 3.5 you can use cl.exe to simply create the objects. Use "/c" to compile only. To get a static lib, you can also use lib.exe, because Interix use the same PE/COFF format like Win32.
If you want a static exe you can also use link.exe from MS to get the app. Use
"/nodefaultlibs /subsystem:posix /entry:__PosixProcessStartup libc.a libpsxdll.a crt0.o my_objects.obj"
as command. Remember to use the Libs out of the Interix SDK, so in Unix -lc stands for libc.a/libc.so. You have to give link.exe the right names, but fortunately the order doesn't matter like with ld, because link makes more than one pass to collect the objects.
I also tried to link to Win32 libs, everything goes well, but the program doesn't run. Seems that the kernel itself really seperates the subsystems, like every FAQ for SfU 3.5 tells you. But I first didn't believe it ;-)
If you want to get shared objects in SfU 3.5 only ld can do the task. cc wrap it into a call of gcc to drive the link process. Myself I never got ld to work without gcc as the frontend, even if i use the same command line for ld wich gives "gcc -v ..." during a link??? But if you want to give a try:
"ld -shared my_objects.obj crti.o -lc -lpsxdll" or similiar, I don't have it in mind at the moment.
But remember: Use this only to get a shared library. An app linked dynamically with shared objects doesn't need the "-shared" switch, because ld builds it by default. To get a real static app you have to add "-static"! Or use link.exe (see above).
Interestingly all POSIX apps are valid PE executables, and shared objects looks like a normal DLL. But a DLL made by link.exe aren't valid shared objects in Posix.
Andreas
< Message edited by jumphigh -- Jan. 12, '06, 10:08:22 AM >
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 4:32:09 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
Thanks for the replies.
About build.exe:
MS state that you can use Visual Studio 2005 to build interix programs. If that is true, using Windows DDK build should/is also be possible. It is probably even safer because the risk of including Win32 headers and libs could be eliminated. As of Windows 2003 SP1 the headers and libs in the DDK and the Platform SDK are in sync and are the same as the ones shipped with Visual Studio 2005.
Problem is: How to use Visual Studio 2005 to build interix programs?
If you set the subsystem to "POSIX", you automatically get entrypoint "__PosixProcessStartup". I also set "/NODEFAULTLIB" to exclude the default Win32 libs. The headers specified in "Additional Include Directories" will have higher priority then the default headers so the local and interix headers specified here must catch any dependencies to avoid inclusion of the default win32 headers.
The "sources" file for DDK build would state (all documented):
UMTYPE=posix
UMENTRYABS=__PosixProcessStartup
TARGETTYPE=PROGRAM
quote:
PS: The link errors you are getting are because you are trying to link Interix and Win32 DLLs that are incompatible with each other.
How and why? I tried 2 alternatives:
1) psxlibc.lib libpsxdll.a crtexe.o
2) libcsafe.a libpsxdll.a safecrt0.o
What about alloca in interix?
I got all info from interix cc (SUA SDK 2006-01-06)
B) # -B static
# -B dynamic
#
case "$OPTARG" in
dynamic)
dynamic=true
linkdll=false
;;
static)
dynamic=false
linkdll=false
if [ ! -z "$DEF_LIBRARIES" ]
then
DEF_LIBRARIES="libcsafe.a libpsxdll.a"
fi
;;
dll)
linkdll=true
dynamic=false
crtfile="crtexe.o"
if [ ! -z "$DEF_LIBRARIES" ]
then
DEF_LIBRARIES="psxlibc.lib libpsxdll.a"
fi
# if the application assumes to use libc.dll this flag is
# necessary to import the global variables from libc.dll
# to the app at compile time
set -A cppoptions ${set_args} "${cppoptions[@]}" "/D_REENTRANT" "/D_IMPORT_LIBCDLL_GLOBALS"
set -A coptions ${set_args} "${coptions[@]}" "/D_REENTRANT" "/D_IMPORT_LIBCDLL_GLOBALS"
;;
I suppose _REENTRANT means thread safe and _IMPORT_LIBCDLL_GLOBALS will define some data needed at runtime. But when you compile with these defines you will get very strange compile errors.
quote:
If you want to get shared objects in SfU 3.5 only ld can do the task. cc wrap it into a call of gcc to drive the link process. Myself I never got ld to work without gcc as the frontend, even if i use the same command line for ld wich gives "gcc -v ..." during a link??? But if you want to give a try:
"ld -shared my_objects.obj crti.o -lc -lpsxdll" or similiar, I don't have it in mind at the moment.
But remember: Use this only to get a shared library. An app linked dynamically with shared objects doesn't need the "-shared" switch, because ld builds it by default. To get a real static app you have to add "-static"! Or use link.exe (see above).
What do you mean? I thought I can link dynamically to psxdll.dll with link.exe and use the CRT-functions exported from psxdll.dll. Have I missed something fundamental? When to use libc.so?
GNU make
Anyone want to try this out, this is a prepared CVS source: GNU make 3.81beta4
configure error: Not so very uncommon with cc, right? Obviously, it expects gcc and cc do not give the right answers. Sometimes this is solved by the "export CFLAGS=/GS-" switch (no dependencies of BufferOverflowU.lib). The whole configure script is 449kB and it is constructed by autoconf. The source above is already prepared with autoconf and is what I used. Maybe running autoreconf again under interix will fix this. config.log just specify the environment not the reason for error. I thought someone have run on to this before and there is some environment switches needed.
regards Jerker
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 5:21:44 PM
|
|
|
jumphigh
Posts: 61
Joined: Jul. 10, '04,
From: Germany
Status: offline
|
Remember, I only have SfU 3.5. Maybe things changed with SUA on W2k3, but in the old 3.5 only ld from the SFU-SDK could build dynamically linked executables.
That means all calls go to libc.so for instance during the runtime of your program. You can check it with Filemon from Sysinternals. If you link with libc.a all needed code is copied into your exe and no lib besides libpsxdll (the glue to the kernel posix subsystem) is touched during the runtime. With a dynamic exe the lib*.so behave like a DLL and will load during the runtime. But as I told you before, all MS linkers before MS 2005 where not able to build such Posix "DLL"s, although I can't tell you at the moment if link.exe can produce a valid app with dynamic linking.
And psxdll is *not* the CRT. It is the POSIX subsystem, that means it includes all the functions the Posix standard defines and it works directly with the native Kernel functions like Win32 does with kernel32.lib.
The CRT is libc.a/libc.so (compare it to statically/dynamically linked MSVCRT/MFC in VS), or in the new "safe"-version libcsafe.a/libcsave.so. AFAIK stands "safe" for new safe string functions with length counting and similiar. You get also such a new CRT for Win32 with VS 2005.
Andreas
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 6:29:05 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
quote:
only ld from the SFU-SDK could build dynamically linked executables.
So this is what cc does? Using ld to link.
If you look in the cc script, you will find 3 alternatives (as I understand it). The default is "static" linking with libcsafe.a libpsxdll.a safecrt0.o
- then you got
"dll" linking with psxlibc.lib libpsxdll.a crtexe.o
- finally there is:
"dynamic" linking which I really don't understand (looked into)
I tried the static linking but as you see above in the first posting I get unresolved externals of alloca. Where is alloca? Should I make my own prototype for alloca like:
void* __cdecl _alloca(size_t);
The "_IMPORT_LIBCDLL_GLOBALS" define used in the "dll" linking seems to have name conflicts with at least "timezone" - struct timezone and "#define timezone (*(long int*)libc_global(G_TIMEZONE)"
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 7:37:07 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Just some slight technical corrections/additions.
The C library functions are in libc for the majority of functions.
There are a couple in PSXDLL that require information from the kernel.
PSXDLL (one of the "jewels") has it's main task as being the communication
layer between Interix programs and the Interix (nee POSIX) subsystem.
The Interix subsystem provides POSIX funtionality, but it provides a lot more
functionality beyond POSIX (aka what was SPEC1170 turned SUS) that makes it a
Unix system.
The shared libraries are structured differently from a Win32 DLL. This is why ld.so
is needed for the load and that Win32 programs don't understand them. So you cannot get
a valid link with a shared library with LINK.EXE on 3.5, In fact you don't get it with SUA
either because a special/different communications layer is used with mixed-mode apps.
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 7:41:59 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> I tried the static linking but as you see above in the first posting I get unresolved externals of alloca. Where is alloca?
It's part of one of the gcc libraries (under the /opt/... directory).
It's part of the malloc() family. But the cc/c89 code uses a different malloc
than gcc. So you need to link against this library as well.
There was another thread recently that covered this (do a search).
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 8:42:44 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
alloca
quote:
It's part of one of the gcc libraries (under the /opt/... directory).
It's part of the malloc() family. But the cc/c89 code uses a different malloc
than gcc. So you need to link against this library as well.
I did try linking to:
libcsafe.a libpsxdll.a safecrt0.o libgcc.a
noop
How could this ever work?
In alloca.h:
#ifdef _MSC_VER
#define alloca(x) _alloca(x)
#endif
#ifdef __GNUC__
#define alloca(x) __builtin_alloca(x)
#endif
Using the MS compiler _MSC_VER is defined and thus alloca is defined as _alloca. However this function have no prototype in the SDK. You mean that somehow the linker will find and satisfy with gcc __builtin_alloca? How to do that? Is that really what MS meant when they wrote alloca.h?
If you look in libc.a (SUA and SFU 3.5) (in a texteditor), you will find an export of "_alloca_probe". This is exactly what my linker is looking for. Maybe it's a reference to something else?
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 8:47:24 PM
|
|
|
markfunk
Posts: 670
Joined: Mar. 31, '03,
Status: offline
|
dynamic libraries:
There are two kinds of dynamic libraries. The UNIX kind, as libX.so and the Windows kind as libX.dll. These are very different from each other. The UNIX kind can only be used in the Interix environment using the gnu ld utility.
dynamic linking:
This is even more complicated, because SUA introduces a -B dll option to /bin/cc.
In SFU3.5, you used -B dynamic to invoke ld instead of LINK.EXE. And there was no distinction between libX.a and libX.lib and there was just crt0.o.
In SUA, they now make a distinction between libX.a and libX.lib and there are several crtXX.o files. I think it all has to do the different kinds of mixed-mode linking.
MS state that you can use Visual Studio 2005 to build interix programs:
They either mean that you can use the CL and LINK utils to build Interix apps via /bin/cc or they mean that it is possible to use the VS IDE gui to build Interix apps. It would be nice if they actually had a config selection that specfically identified SUA/Interix.
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 9:32:08 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
This solved it:
#define _alloca(x) _alloca_probe(x)
The executable produced (235kB) is not functional though.
Korn shell:
$ make_gcc -v
GNU Make 3.81beta4
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
This program built for i586-pc-interix5
$make_vstest -v
Memory fault (core dumped)
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 11:10:36 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
I put myself the question:
Is my GNU make compilation OK? Maybe not, lets try somthing more simple:
interix_test.cpp
#include <unistd.h>
#include <stdio.h>
int main()
{
printf("This is interix %u\n",_POSIX_VERSION);
return 0;
}
Static linking with libcsafe.a libpsxdll.a safecrt0.o => 64kB
"dll" linking with psxlibc.lib libpsxdll.a crtexe.o => 6kB
Both give the following in Korn shell:
$ ./test_interix
This is interix 199009
yesss!!
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 12, '06, 11:32:21 PM
|
|
|
jumphigh
Posts: 61
Joined: Jul. 10, '04,
From: Germany
Status: offline
|
And now run "strip" over the executables and compare sizes! ;-)
But besides that, I really don't understand why MS made dynamic linking different in Win32 and SfU/SUA.
The file format is all PE, you can run every PE tool (depends.exe etc.) on a libX.so, and you'll get valid answers. So the question is: How get Posix apps loaded?
As I understand the Win loader is part of the kernel, so whether you load a Win32 or a Posix exe, everythig should be done by this loader. And I guess since depends give all imports/exports from a libX.so that the loader is able to read a Posix app with all dependecies without the help of the Posix subsystem. But you need ld.so to resolve the dynamic libs for a posix app??? Because what?
Andreas
PS: Does somebody got the --list/--verify options of ld.so to work? I never got a list of the neeeded "libX.so"s.
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 13, '06, 2:16:58 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
my mistake - there is some magic about _alloca. It's there as is _alloca__probe, but not _alloca_probe_8 and _alloca_probe_16.
So I made a new source file as this from alloca16.asm:
alloca_probe.cpp
extern "C" void _chkstk();
//_alloca_probe_16 : 16 byte aligned alloca
extern "C" void _alloca_probe_16()
{
__asm
{
push ecx
lea ecx, [esp] + 8 ; TOS before entering this function
sub ecx, eax ; New TOS
and ecx, (16 - 1) ; Distance from 16 bit align (align down)
add eax, ecx ; Increase allocation size
sbb ecx, ecx ; ecx = 0xFFFFFFFF if size wrapped around
or eax, ecx ; cap allocation size on wraparound
pop ecx ; Restore ecx
jmp _chkstk
}
}
//alloca_8: 8 byte aligned alloca
extern "C" void _alloca_probe_8()
{
__asm
{
push ecx
lea ecx, [esp] + 8 ; TOS before entering this function
sub ecx, eax ; New TOS
and ecx, (8 - 1) ; Distance from 8 bit align (align down)
add eax, ecx ; Increase allocation Size
sbb ecx, ecx ; ecx = 0xFFFFFFFF if size wrapped around
or eax, ecx ; cap allocation size on wraparound
pop ecx ; Restore ecx
jmp _chkstk
}
}
Scary but compiled and success!!!
Static linking to libcsafe.a libpsxdll.a safecrt0.o
Visual Studio 2005 - No special switches other then mentioned above
make 232 kB
Perl tests:
quote:
$ perl ./run_make_tests
-----------------------------------------------------------------------------
Running tests for GNU make on Interix max 5.2 x86
GNU Make 3.81beta4
-----------------------------------------------------------------------------
Clearing work...
Finding tests...
features/comments ....................................... ok (1 passed)
features/conditionals ................................... ok (4 passed)
features/default_names .................................. ok (3 passed)
features/double_colon ................................... ok (10 passed)
features/echoing ........................................ ok (4 passed)
features/errors ......................................... ok (2 passed)
features/escape ......................................... ok (6 passed)
features/export ......................................... ok (10 passed)
features/include ........................................ ok (7 passed)
features/mult_rules ..................................... ok (2 passed)
features/mult_targets ................................... ok (2 passed)
features/order_only ..................................... ok (10 passed)
features/override ....................................... ok (1 passed)
features/parallelism .................................... ok (5 passed)
features/patspecific_vars ............................... ok (7 passed)
features/patternrules ................................... ok (5 passed)
features/quoting ........................................ ok (1 passed)
features/recursion ...................................... ok (2 passed)
features/reinvoke ....................................... ok (4 passed)
features/se_explicit .................................... ok (5 passed)
features/se_implicit .................................... ok (8 passed)
features/se_statpat ..................................... ok (4 passed)
features/statipattrules ................................. ok (6 passed)
features/targetvars ..................................... ok (18 passed)
features/varnesting ..................................... ok (1 passed)
features/vpath .......................................... ok (1 passed)
features/vpath2 ......................................... ok (1 passed)
features/vpathgpath ..................................... ok (1 passed)
features/vpathplus ...................................... ok (4 passed)
functions/abspath ....................................... ok (1 passed)
functions/addprefix ..................................... ok (1 passed)
functions/addsuffix ..................................... ok (2 passed)
functions/basename ...................................... ok (1 passed)
functions/call .......................................... ok (2 passed)
functions/dir ........................................... ok (1 passed)
functions/error ......................................... ok (4 passed)
functions/eval .......................................... ok (9 passed)
functions/filter-out .................................... ok (1 passed)
functions/findstring .................................... ok (1 passed)
functions/flavor ........................................ ok (1 passed)
functions/foreach ....................................... ok (2 passed)
functions/if ............................................ ok (1 passed)
functions/join .......................................... ok (1 passed)
functions/notdir ........................................ ok (1 passed)
functions/origin ........................................ ok (1 passed)
functions/realpath ...................................... ok (1 passed)
functions/shell ......................................... ok (2 passed)
functions/sort .......................................... ok (1 passed)
functions/strip ......................................... ok (2 passed)
functions/substitution .................................. ok (3 passed)
functions/suffix ........................................ ok (1 passed)
functions/value ......................................... ok (1 passed)
functions/warning ....................................... ok (4 passed)
functions/wildcard ...................................... ok (3 passed)
functions/word .......................................... ok (9 passed)
misc/close_stdout ....................................... ok (1 passed)
misc/general1 ........................................... ok (1 passed)
misc/general2 ........................................... ok (1 passed)
misc/general3 ........................................... ok (10 passed)
misc/general4 ........................................... ok (6 passed)
options/dash-B .......................................... ok (7 passed)
options/dash-C .......................................... ok (2 passed)
options/dash-I .......................................... ok (3 passed)
options/dash-W .......................................... ok (7 passed)
options/dash-e .......................................... ok (1 passed)
options/dash-f .......................................... ok (4 passed)
options/dash-k .......................................... ok (3 passed)
options/dash-l .......................................... ok (0 passed)
options/dash-n .......................................... ok (4 passed)
options/dash-q .......................................... ok (8 passed)
options/dash-t .......................................... ok (2 passed)
options/general ......................................... ok (1 passed)
options/symlinks ........................................ ok (10 passed)
targets/DEFAULT ......................................... ok (1 passed)
targets/FORCE ........................................... ok (1 passed)
targets/INTERMEDIATE .................................... ok (8 passed)
targets/PHONY ........................................... ok (1 passed)
targets/SECONDARY ....................................... ok (8 passed)
targets/SILENT .......................................... ok (1 passed)
targets/clean ........................................... ok (2 passed)
variables/CURDIR ........................................ ok (1 passed)
variables/DEFAULT_GOAL .................................. ok (4 passed)
variables/INCLUDE_DIRS .................................. ok (2 passed)
variables/MAKE .......................................... ok (1 passed)
variables/MAKECMDGOALS .................................. ok (3 passed)
variables/MAKEFILES ..................................... ok (1 passed)
variables/MAKELEVEL ..................................... ok (1 passed)
variables/MAKE_RESTARTS ................................. ok (3 passed)
variables/MFILE_LIST .................................... ok (1 passed)
variables/SHELL ......................................... ok (5 passed)
variables/automatic ..................................... ok (5 passed)
variables/flavors ....................................... ok (10 passed)
variables/special ....................................... ok (1 passed)
323 Tests in 93 Categories Complete ... No Failures :-)
$
I'm truly pleased
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 14, '06, 7:08:38 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
So, I have been playing around with this for a while.
Dynamic linking to psxlibc.dll:
It seems that the _alloca_probe_8/16 problem is due to wrong compiler/linker settings. I am convinced that _alloca_probe(_chkstk) is missing from psxlibc.lib (and not exported from psxlibc.dll). To solve this you can link directly to ntdll.dll (you will need ntdll.lib from the Windows DDK). This gives:
linking to psxlibc.lib libpsxdll.a crtexe.o ntdll.lib
make 114kB - perl tests 100% OK
Examining the executable in depends.exe gives dependencies to ntdll.dll, psxlibc.dll and psxdll.dll. It looks like the linker relocated some CRT references from psxlibc to ntdll directly. I suppose that is more efficient and it seems to work so far (is there any differences in the CRT one may wonder?).
I never succeded in building GNU make in Visual Studio without my fake _alloca_probe_# functions. I tried to change the settings in any possible way - no luck. The above make is made by the Windows DDK build utility. Unfortunatly MS have removed the posix option in the DDK makefiles (why?). One can enable posix builds by injecting this simple addition in makefile.new (Windows DDK 2003 SP1):
bin\makefile.new - line:1766 - right after the os2 subsystem
!ELSEIF "$(UMTYPE)" == "posix"
SUBSYSTEM=posix # empty, linker generated version
UMENTRY=-entry:__PosixProcessStartup
386_STDCALL=0 # __cdecl calling convention
BUFFER_OVERFLOW_CHECKS=COMPILE_ONLY # no bufferoverflowu.lib
NOT_TERMINAL_SERVER_AWARE=1
UMINCL=$(CRT_INCLUDES)
UMLIBS=$(UMLIBS)
My build sources file for GNU make:
GNUmake\winddk\sources
# Windows DDK utility build sources file for GNU make
# ---- types of build ----
STATIC_LINK=1
DLL_LINK=0
# ---- names and paths ----
TARGETNAME=make
TARGETTYPE=PROGRAM
TARGETPATH=..\bin
CRT_INC_PATH=$(SYSTEMROOT)\SUA\usr\include;$(SYSTEMROOT)\SUA\usr\include\sys
SUA_LIB_PATH=$(SYSTEMROOT)\SUA\usr\lib
# ---- compiler settings ----
UMTYPE=posix
UMENTRYABS=__PosixProcessStartup
INCLUDES=.;..;..\glob
MSC_WARNING_LEVEL=/W4
COMPILER_WARNINGS=/wd4005 /wd4007 /wd4018 /wd4028 /wd4100 /wd4115 /wd4127 \
/wd4130 /wd4131 /wd4189 /wd4210 /wd4242 /wd4244 /wd4245 \
/wd4267 /wd4307 /wd4311 /wd4389 /wd4706
USER_C_FLAGS=/D"_CONSOLE" /D"HAVE_CONFIG_H" /D"__INTERIX" /D"_ALL_SOURCE"
# ---- linker settings ----
LINKER_FLAGS=$(LINKER_FLAGS) /ignore:4199,4210
STATIC_LINK_LIBS= \
$(SUA_LIB_PATH)\libcsafe.a \
$(SUA_LIB_PATH)\libpsxdll.a \
$(SUA_LIB_PATH)\safecrt0.o
DLL_LINK_LIBS= \
$(SUA_LIB_PATH)\psxlibc.lib \
$(SUA_LIB_PATH)\libpsxdll.a \
$(SUA_LIB_PATH)\crtexe.o
!IF $(STATIC_LINK)
NO_NTDLL=1
USE_NOLIBS=1
TARGETLIBS=$(STATIC_LINK_LIBS)
!ELSEIF $(DLL_LINK)
USE_NTDLL=1
TARGETLIBS=$(DLL_LINK_LIBS)
!ENDIF
# ---- project files ----
SOURCES= \
make.rc \
..\ar.c \
..\arscan.c \
..\commands.c \
..\default.c \
..\dir.c \
..\expand.c \
..\file.c \
..\function.c \
..\getloadavg.c \
..\getopt.c \
..\getopt1.c \
..\hash.c \
..\implicit.c \
..\job.c \
..\main.c \
..\misc.c \
..\read.c \
..\remake.c \
..\remote-stub.c \
..\rule.c \
..\signame.c \
..\variable.c \
..\version.c \
..\vpath.c \
fnmatch.c \
glob.c
static linking - 228kB - perl test 100% OK
dynamic linking - 114kB - perl test 100% OK
also tested stdcall calling convention - OK
Hope someone will find something useful in this SUA test.
regards jerker
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 15, '06, 12:47:26 PM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
Just a note:
cc and configure works OK. My mistake - the problem was just spaces in the path.
Simple comparsion of builds:
gcc 466 kB tests OK opt -O2
cc 308 kB tests OK opt -O2
VS2005 231 kB tests OK opt -Oxtiy (not quite correct)
DDK 228 kB tests OK opt -Oxs
Dynamic linking to psxlibc.dll
DDK 114 kB tests OK opt -Oxs
It seems to me that we need some guidence from MS how to use Visual Studio with interix and for myself, I go for the Windows DDK build utility.
|
|
|
|
|
RE: SUA linking in Visual Studio - how to? - Jan. 17, '06, 12:26:17 AM
|
|
|
jerker_back
Posts: 68
Joined: Jul. 7, '05,
From: Sweden
Status: offline
|
Just a note2:
Will this work in SFU 3.5?
To find out I used the SFU 3.5 SDK (headers and libs)
First: MS says that binaries from SFU will run in SUA, so a GNU make compiled with the SFU SDK should run in my SUA environment.
The SFU SDK do not have the security enhancements so you need to omit the /GS and /safeseh switches:
NO_SAFESEH=1
NO_BUFFER_OVERFLOW_CHECKS=1
linking to libc.a libpsxdll.a crt0.o
Windows DDK 2003 SP1: make 206 kB opt: Oxs
Visual Studio 2005: make 230 kB opt: Oxt
The binary worked perfectly in SUA and run all GNU make perl tests OK. However, a test in a clean install of SFU 3.5 on Windows 2003 SP1 (no /Tools or patches) did not work as good. It run some of the tests OK, failed some and finally bailed out with a signal error. I don't know the reason for the errors. Maybe it's something wrong with my compiled make or something wrong with SFU 3.5 on Win2003 SP1. Most important: It did run on SFU!
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
