Re: Msys 2 Work in progress

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Den 10-09-2011 19:29, Charles Wilson skrev:
> On 9/10/2011 10:55 AM, Ralph Engels wrote:
>> Also having some difficulty removing /cygdrive (the code changed
>> considerable).
> 
> Cygwin now allows /etc/fstab to change the "default" value of the 
> cygdrive prefix from "/cygdrive" to whatever the user wants. Many
> choose to set it to "/" -- which is what we want here, although we
> want to do it in code, rather than in the /etc/fstab file.
> 
> It should simply be a matter of us changing the default value of 
> cygdrive_prefix, wherever it is defined, from "/cygdrive" to "/"
> 
>> Unfortunatly it seems the dll depends on libcygserver.a + some
>> source files from it
> 
> modern cygwin cooperates with the cygserver daemon -- *if present
> and running* -- in order to support certain IPC facilities.  So,
> the daemon has an API, and cygwin dll uses it.  Now, you don't HAVE
> to have the daemon running, and cygwin will just return ENOSYS when
> the user tries to use the facilities that need cygserver for proper
> operation.  So, you don't need to port cygserver *itself* -- just
> enough of the "interface code" -- that is, libcygserver.a -- so
> that it can always return "sorry, cygserver not running; please
> fail whatever operation the user was trying to do".
> 
>> One question i hope someone can help me with. Since i removed
>> cygwins internal mingw some tools cannot be built since they rely
>> on the mingw compiler + libraries/includes. Is there any way to
>> tell it that i want to use the external mingw without making a
>> wholy mess in the makefiles ?.
> 
> Not sure.  I'm not clear what they've changed in the cygwin build 
> system, now that the "cygwin" compiler no longer support
> -mno-cygwin and they have to rely on either (cygwin-gcc with
> -no-stdlib -no-stdinc -I/mingw/include/path etc etc) OR
> (where-is-mingw-cross-compiler...).
> 
> If they are doing the former, then you ought to be able to do that
> too, with msys-gcc -no-stdlib -no-stdinc -I/usr/include/mingw 
> -I/usr/include/w32api -L/usr/lib/mignw -L/usr/lib/w32api etc etc.
> 
> Hmm...well, we have the .../w32api stuff, since we provide an 
> msys-w32api package.  But we don't currently provide an
> msys-mingwrt package, so /usr/include/mingw and /usr/lib/mingw
> don't exist. Maybe we should?
> 
> -- Chuck
> 
> ------------------------------------------------------------------------------
>
> 
Malware Security Report: Protecting Your Business, Customers, and the
> Bottom Line. Protect your business and customers by understanding
> the threat from malware and how it can impact your online business.
>  http://www.accelacomm.com/jaw/sfnl/114/51427462/ 
> _______________________________________________ Mingw-msys mailing
> list [email protected] 
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
Tried setting the default cygdrive prefix to / but that crashes the
dll. I managed to do it some other (complicated) way which seems to
work except for having trouble bootstrapping a gcc build with mingw.
It might have been related to a previous problem i had where uname
refused to accept the values from the MSYSTEM var even though i added
the code specifically. I found out that the cygwin team had changed
the way it looked for forced env variables but it was a pain in the
proverbial behind to figure out which boolean in the table turned the
correct variable on (no documentation besides that it was changed).
Besides the fixes i managed to get it building itself besides 2 of the
tools (cygserver.exe & cygcheck.exe) the rest builds now. cygcheck
depended on the mingw that normally came with the source so adjusting
the makefile to use the external mingw should fix that. cygserver
fails with unknown reference to vtable hmm ? i tried adding libstdc++
as that is normally the cause for those errors but that didnt quite
cut it. Ideas are welcome.

Updated gcc to 4.4.6 for the build environment as the old 3.3.4 cannot
cope with it. (cannot be used with the old msys unfortunatly) :/

ill keep the diff of a little longer untill it can build itself fully.

In regards to including the mingw runtime like cygwin does. I wouldnt
mind and it will be a whole lot easier to get things going. I was just
afraid it might interfere with seperate mingw mingw mounts, but if
that aint the case then i see no reason not to. Will also help
immensly in porting tools.

Ralph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOa6oaAAoJEIjGvG7Y4HU8A58H/3447xmnk/3qr5NsBVu1t8im
S4xbz5hYY9LJwKVilWppTWfxWynXeP46w79qq6dxEl3lEnJ6vD5Su2/xMo7JcQVU
LGS0QQCv82CYTg3ojYoR/8gmV/bYVyDrPrY6ubE1jNrDGbo2scO48GuEnRJPWYdR
7pMb917KqKVgD2N7g+/XcumckUw5YaQujOUIbB/Bq327Zueu8ulSuW9EMF2SsvAO
R7hK6E+Gqqrx7Z+KvoGYmINBvUxHe+IdmqY8YzlGG9A70zmDd3J8O6u1AeddHvrI
u1sbsi5TIx1OQzQhkvYy0PSZx8w13Ht/HMZPAejXbJ8RZfDt9RNs5/Lvc477hfY=
=lB/l
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Malware Security Report: Protecting Your Business, Customers, and the 
Bottom Line. Protect your business and customers by understanding the 
threat from malware and how it can impact your online business. 
http://www.accelacomm.com/jaw/sfnl/114/51427462/