Mesaje recente

Members
Stats
  • Total Posts: 17,786
  • Total Topics: 1,234
  • Online today: 211
  • Online ever: 340
  • (22 November 2024, 00:10)
Users Online
Users: 0
Guests: 95
Total: 95

Visual Studio POSIX development

Started by ~Empathy~, 29 November 2006, 17:12

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

~Empathy~

Am vrut sa testez astazi Windows POSIX subsystem si am incercat sa compilez ceva soft cu Visual Studio 2005. E doar o idee tampita de-a mea, nu vad de ce ar face cineva asa ceva.

Surpriza, NU exista documentatie. Deloc. Nici macar nu se aminteste undeva ca Visual Studio poate sa faca binare POSIX. A trebuit sa ma prind singur ce si cum.

Ok, se incepe cu proiect empty, in care punem un "Hello, world" si facem urmatoarele modificari.

optiuni cl.exe
/D__INTERIX /D_ALL_SOURCE /D_REENTRANT /U_WIN32 (D_IMPORT_LIBCDLL_GLOBALS)

Destul de evident. Compilam pentru Interix.

/I$(SYSTEMROOT)\SUA\usr\include

Folosim fisierele include din SUA...

/X

...si NUMAI alea.

Alte optiuni dupa caz/gust.

Pentru linker folosim urmatoarele optiuni:

/LIBPATH:$(SYSTEMROOT)\SUA\usr\lib
/NODEFAULTLIB


Folosim NUMAI bibliotecile din SUA.

/SUBSYSTEM:POSIX

Trebuie sa rezulte un executabil POSIX...

/ENTRY:__PosixProcessStartup
...care-si incepe executia la __PosixProcessStartup.

/MACHINE:X86
Compilam pentru x86.

Folosim urmatoarele biblioteci:

libpsxdll.a psxlibc.lib crtexe.o

Evident adaugam altele dupa caz (ex: libstdc++ etc).

Aplicatia obtinuta in acest mod are o mica problema. Trebuie rulata cu urmatoarea comanda:

posix /c posixapp.exe

Daca rulam direct nu merge. De ce? Nu stiu. Trebuie sa investighez. Cert e ca o aplicatie compilata cu gcc-ul din SUA merge fara artificiul asta.

Bun, acuma trecem la aplicatii mai complicate decat "Hello, world".
Surpriza! O sa primiti erori de genul:

"C:\WINDOWS\SUA\usr\include\c++\vadefs.h(37) : fatal error C1189: #error :  ERROR: Use of C runtime library internal header file."

Daca ne uitam in fisierul ala vedem ce scrie:

#if !defined(_MS_SUA_)
#ifndef _CRTBLD
/* This version of the header files is NOT for user programs.
* It is intended for use when building the C runtimes ONLY.
* The version intended for public use will not have this message.
*/
#error ERROR: Use of C runtime library internal header file.
#endif  /* _CRTBLD */
#endif /* !defined(_MS_SUA_)*/


Ce stupid. Programul cu care am testat include cstring care include yvals.h care include crtdefs.h care include vadefs.h

Evident pot sa definesc _CRTBLD si va merge, dar nu ar trebui sa fac asa ceva. Exista niste headere in \Interix, de exemplu Interix\interix.h si \Interix\env.h care am crezut initial ca ar avea ceva de-a face cu cu niste constante definite pentru a putea compila programe Interix, dar nu e asa. Fisierele respective nu au nicio legatura.

Eh trecem peste asta si incercam altceva. Ce ar fi de exemplu daca am include headerele obisnuite si nu cele din Interix? Am incercat si de data asta sursele se compileaza fara probleme dar nu se linkeaza. Sa investigam de ce.


...
...ray.obj : error LNK2019: unresolved external symbol _memmove_s referenced in function "public: static char * __cdecl std::char_traits::_Move_s(char *,unsigned int,char const *,unsigned int)" (?_Move_s@?$char_traits@D@std@@SAPADPADIPBDI@Z)
ray.obj : error LNK2019: unresolved external symbol "public: __thiscall std::exception::exception(char const * const &)" (??0exception@std@@QAE@ABQBD@Z) referenced in function "public: __thiscall std::bad_alloc::bad_alloc(char const *)" (??0bad_alloc@std@@QAE@PBD@Z)
ray.obj : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
ray.obj : error LNK2001: unresolved external symbol "public: virtual char const * __thiscall std::exception::what(void)const " (?what@exception@std@@UBEPBDXZ)
ray.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall std::exception::~exception(void)" (??1exception@std@@UAE@XZ) referenced in function "public: virtual __thiscall std::bad_alloc::~bad_alloc(void)" (??1bad_alloc@std@@UAE@XZ)
ray.obj : error LNK2019: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) referenced in function "public: virtual void * __thiscall std::bad_alloc::`scalar deleting destructor'(unsigned int)" (??_Gbad_alloc@std@@UAEPAXI@Z)
ray.obj : error LNK2019: unresolved external symbol __Inf referenced in function "public: static double __cdecl std::numeric_limits::infinity(void)" (?infinity@?$numeric_limits@N@std@@SANXZ)
...
...


Ciudat ciudat... crtexe.o ala ne da peste cap planurile tampite de a compila programe POSIX Sa-l stergem. Dar... daca il stergem... Cu ce il inlocuim? Pai cu libc.a, daca tot avem o biblioteca standard SUA. Vom obtine mult mai putine erori de linkare.


ray.obj : error LNK2019: unresolved external symbol __ftime64 referenced in function _ftime
ray.obj : error LNK2019: unresolved external symbol __CIsqrt referenced in function "struct Vec __cdecl unitise(struct Vec const &)" (?unitise@@YA?AUVec@@ABU1@@Z)
ray.obj : error LNK2001: unresolved external symbol __purecall
ray.obj : error LNK2019: unresolved external symbol __invalid_parameter_noinfo referenced in function "public: bool __thiscall std::list >::_Const_iterator<1>::operator==(class std::list >::_Const_iterator<1> const &)const " (??8?$_Const_iterator@$00@?$list@PAUScene@@V?$allocator@PAUScene@@@std@@@std@@QBE_NABV012@@Z)
ray.obj : error LNK2019: unresolved external symbol ___iob_func referenced in function _main

Le analizam si observam ca alea sunt niste functii interne din biblioteca standard MS (NTDLL) care lipsesc cu desavarsire din SUA. Solutia e simpla dar proasta. Se dezasambleaza din runtime-ul MS functiile lipsa si se compileaza la loc.

ml.exe /D_POSIX_ /X /I<mscrtpath> /coff /safeseh /W3 /Zi /Zp8 /Gd /Cx /c mssfnct.asm.

Voila, merge! Se pune problema la ce bun? de ce nu e documentat nimic? de ce nu merge by default?

Inca ceva. SUA vine cu add-on la Visual Studio pentru a putea face debugging la programe POSIX. Evident ca nu merge.
We dance, and the music dies...

kman

Just a stupid idea, dar cred ca MS nu prea a intentionat ca cineva chiar sa foloseasca SUA/SFU, daca ne uitam la starea deplorabila a SFU3.5, la care trebuie sa faci o groaza de tweaking ca sa-l poti folosi cu adevarat.

Oricum cred ca cel mai simplu ti-ar fi, daca vrei sa faci aplicatii posix pe windows, sa folosesti gcc-ul din interix si nu Visual Studio.

Deci ... doar un moft, nimic mai mult.

In alta ordine de idei, foarte interesant ce zici tu acolo, poate imi omor si eu un weekend cu dracia asta.