This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: generating debug info for SingleStep Debugger


yy_tseng wrote:
> 
> It's a huge job to alternative cygwin..
> 
> Is there another soluation  to modify gcc source code?

 If you meaned that duplicating Cygwin doesn't sound sane, I must agree...

 Porting the GNU-sources better for Mingw should be much better. Some known
non-workings on Mingw-host I remember now are :

 - the collect2.c in the GCC-sources, should be now known...

 - the GNU ld not finding the 'linked' shared libs told only in the defined
   shared libs (e.g. 'libc.so.6' needing symbols from 'ld-linux.so.2' with
   the Linux-targets)

 - the network-operations in GDB, now ported only to the BSD-like sockets in
   Cygwin, not for Winsock(2) in Mingw

 - the tcl/tk-8.3 etc. stuff used in gdb/insight-5.2 probably isn't ported to
   Mingw yet, but using any MSVC or BCC built DLLs with Mingw-hosted executables
   shouldn't bring any problems...

 The problem is that most Mingw-people see only the Mingw-host/Mingw-target
as the only needed combination on the Windows-host. Other targets like the
embedded systems, Linux'es, Solaris2 etc. aren't interesting at all. I have
been one of the 'aliens' with weird thoughts there...

 If one has a thought that embedded target tools for Windows should run on
the native Win32-API and MSVCRT/CRTDLL-layer, not on any Unix-emulating layer
like Cygwin, feel free to work for this goal !

 We already have suitable and cheap build-hosts like Linux, FreeBSD, NetBSD
etc. and people can produce Win32-hosted tools on them after first building
the needed 'Mypreferredhost-x-Mingw' cross-tools (binutils + GCC) there, or
downloading a prebuilt toolchain somewhere. A Linux-x-Mingw toolchain with
gcc-2.95.2 or 2.95.3 should be available. But if someone feels so dummy that
thinks being uncapable to build a cross-compiler on Linux, then it is better
to stay producing only those 'usual' Win32-apps there... If one considers to
build several Mingw-hosted cross-tools, then the Linux-x-Mingw toolchain
serves as a very good practice before the first Mingw-hosted toolchain. Just
as the needed Linux-hosted toolchain for the aimed embedded target -- one
must have a toolchain to produce the 'libgcc.a's for the target on the build
host, otherwise the 'make all-gcc' will be enough, the Linux-hosted toolchain
already has the 'libiberty.a's and 'libstdc++.a's for the target... But
disabling the 'libgcc.a' rebuilds is harder than just letting them to be built
again... Anyway one must get them from somewhere.

 My wish would be that people could concentrate on producing Windows-hosted
tools instead of trying desperately to do all the builds on Windows, or trying
to create one Unix-clone more (Windows+MSYS) when there already are several
suitable free Unix-like ones available...

 For instance a 'real' Cygwin-x-Mingw cross-compiler would serve as a Mingw-
target toolchain much better than the current '-mno-cygwin', but as I have
understood, even using the 'native' Mingw-GCC with all the Cygwin's Unix-tools
shouldn't bring any problems.

 I prefer to use only one host on a run-platfoem, so my Cygwin-target toolchain
(binutils and GCC) on Windows32 is also Mingw-hosted, I need only the 'cygwin1.dll'
from the Cygwin-distribution (besides the headers and libs) for running the produced
executables.  On DOS/Win3.1x/Win32s all my cross-tools of course are DJGPP2-hosted,
I don't understand those people mixing DJGPP2, Mingw and Cygwin stuff on the same
platform...

 Ok, the native Windows runtime-environment (MSVCRT.DLL or CRTDLL.DLL, WINSOCK.DLL
or WSOCK32.DLL ...) must have something badly wrong because the Windows-users
don't like them, but want a Unix-like runtime-environment with Unix-functions
like 'fork()', BSD-sockets etc. to replace them. It would be nice if the
Windows-people could tell us what the problem is...  It is true that there are
some people who don't know anything about the Win32-API and therefore would
need those Unix-like layers to work with, but as I have understood there must
be some people now who have at least heard someone talking about the Win32-API,
Winsock etc... People who know the Win32-API would be required to convert those
Unix-dependent operations in 'collect2.c' in GCC-sources and the network-operations
in GDB-sources to use the native Win32-API...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]