Re: 20060529: python and semaphores
Christopher Faylor schrieb: On Tue, May 30, 2006 at 09:18:56PM -0500, Yaakov S (Cygwin Ports) wrote: snip Unless I'm missing something, the backtrace is useless and probably doesn't show a real problem. It is just YA example of the OMG! I get SIGSEGV's in GDB problem which we must discuss every day here. One more reason to have an updated gdb binary package. Is nobody there who can make a gdb binary package instead that everyone has to compile it by himself ? Making a package is not very much work, giving support more. As starting point I've made a binary snapshot located on http://webdev.cegit.de/snapshots/cygwin/ Regards Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: note about how-to-debug-cygwin.txt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor schrieb:
On Sun, May 28, 2006 at 10:59:35PM +0200, Ralf Habacker wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In the how-to-debug-cygwin.txt there is listed how to run application
using strace in gdb:
To debug this scenario, do something like this:
bash$ gdb -nw yourapp.exe
(gdb) dll cygwin1
(gdb) l dll_crt0_1
(gdb) b first line in the function
(gdb) run
(gdb) set strace.active=1
(gdb) continue
According to winsup/cygwin/include/sys/strace.h the class member active
is known now as _active.
I've changed this.
I have tried to get this running in gdb (cvs), but there is no output in
gdb.
Getting output from gdb was not the intent of this section. Look at the
name of the section: Program dies when running under strace. If the
intent was to get output from gdb it would have been something like
Make gdb output strace info.
It was not explicit said that there is no output, so I guess it was.
I'm not aware of any way to have gdb print strace info.
The following patch enables gdb to print cygwin strace messages.
2006-05-29 Ralf Habacker [EMAIL PROTECTED]
* win32-nat.c: (handle_output_debug_string): initial strace
output support for cygwin.
Index: gdb/win32-nat.c
===
RCS file: /cvs/src/src/gdb/win32-nat.c,v
retrieving revision 1.122
diff -u -b -B -r1.122 win32-nat.c
- --- gdb/win32-nat.c 10 Apr 2006 21:43:45 - 1.122
+++ gdb/win32-nat.c 29 May 2006 11:19:49 -
@@ -927,7 +927,12 @@
/* nothing to do */;
else if (strncmp (s, _CYGWIN_SIGNAL_STRING, sizeof
(_CYGWIN_SIGNAL_STRING) - 1) != 0)
{
- - if (strncmp (s, cYg, 3) != 0)
+ if (strncmp (s, cYg, 3) == 0)
+{
+ char *p = strchr(s+12,' '); // skip 'cYg category'
+ printf_unfiltered (strace: %s, p ? p+1 : s+12);
+}
+ else
warning ((%s), s);
}
#ifdef __COPY_CONTEXT_SIZE
===
Regards
Ralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEetqEoHh+5t8EXncRAuhNAJ9ox5IHUnkqZL93hQejih0HuIraIQCglMhg
22SIlwNUvNgbx6dfzMYe640=
=gqy2
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent schrieb: Ralf Habacker wrote: There is only one case where I still believe that there may be a problem. If a pthread_mutexattr_t is constructed on the stack and the magic class membere is be exactly the predefined value, pthread_mutexattr_init() will return EBUSY, although there is no good object, it is only by random. I believe this has been hashed out on the list before as well. I think the conclusion is that the app needs to check the return values so that it can cope with this case. I don't have a link to the thread handy. My currently conclusion is that there are rare conditions in the pthread and/or exception stuff, which corrupts the stack and that there is more work required to find out the problem. This I don't doubt, but I think it will just require someone digging in. If you can whittle down the qt3 stack overflow crash to a testcase, then there's a good chance someone reading will give it more attention. I just downloaded cywin snapshot 2005-06-27 and got running designer and uic without any problem, so it looks like there is no need to deep more into this stuff. I will follow the next time if this problems takes places again. Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeYPUoHh+5t8EXncRAp+gAKCCzeyZYaEuwvRiaDL2FB/hYGPAjQCeJSH2 /BqF8kRfoLwrWOBQMLA21wg= =PPbt -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Habacker schrieb: Brian Dessent schrieb: Ralf Habacker wrote: There is only one case where I still believe that there may be a problem. If a pthread_mutexattr_t is constructed on the stack and the magic class membere is be exactly the predefined value, pthread_mutexattr_init() will return EBUSY, although there is no good object, it is only by random. I believe this has been hashed out on the list before as well. I think the conclusion is that the app needs to check the return values so that it can cope with this case. I don't have a link to the thread handy. My currently conclusion is that there are rare conditions in the pthread and/or exception stuff, which corrupts the stack and that there is more work required to find out the problem. This I don't doubt, but I think it will just require someone digging in. If you can whittle down the qt3 stack overflow crash to a testcase, then there's a good chance someone reading will give it more attention. I just downloaded cywin snapshot 2005-06-27 and got running designer and uic without any problem, so it looks like there is no need to deep more into this stuff. I will follow the next time if this problems takes places again. Many thanks to Chris and Gary. :-) Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeeqQoHh+5t8EXncRAmMNAJ4s2vN/ZW74vbwursRd00KxFqMNjgCdGwaV FKdBdtiuyZoHAHkgn10zWw8= =tVok -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
note about how-to-debug-cygwin.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In the how-to-debug-cygwin.txt there is listed how to run application using strace in gdb: To debug this scenario, do something like this: bash$ gdb -nw yourapp.exe (gdb) dll cygwin1 (gdb) l dll_crt0_1 (gdb) b first line in the function (gdb) run (gdb) set strace.active=1 (gdb) continue According to winsup/cygwin/include/sys/strace.h the class member active is known now as _active. I have tried to get this running in gdb (cvs), but there is no output in gdb. May be I have understand something wrong and the output is printed somewhere else, but the sources tell me that strace uses OutputDebugString(), which should be catched by gdb. Or does gdb print it only when the application is currently running in gdb and not in the gdb prompt ? Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeg83oHh+5t8EXncRAnZtAJ0XI2URyUgm9n9nMxpjQWoXi5baJACdHFqP eNp6sUbJ8SiueHKsXnf76Vs= =k0v+ -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Korn schrieb: On 24 May 2006 13:19, Ralf Habacker wrote: This breakpoint is never reached (at least in released gdb) and makes it hard to debug cygwin's threading stuff, probably impossible in this area. How many times do you have to be told? The last released gdb is known to not cope with this. IT IS A KNOWN BUG. IT HAS BEEN FIXED. I have downloaded and compiled gdb weekly snapshot (20060522), but there are still problems with tracing after an internal exception occured. I am using testcase mutex1n.c from cvs path src/winsup/testsuite/winsup.api/pthread and set a breakpoint to pthread_mutexattr_init Breakpoint 1, pthread_mutexattr_init (attr=0x404040) at /netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/cygtls.h:253 1: x/i $eip 0x610b0f07 pthread_mutexattr_init+7: lea 0xff08(%ebp),%esi (gdb) ni snip 0x610b1005 129 in /netrel/src/cygwin-snapshot-20060522-1/winsup/cygwin/thread.cc 1: x/i $eip 0x610b1005 pthread_mutexattr_init+261: cmpl $0xdf0df049,0x4(%eax) (gdb) here the internal exception occurs and gdb is out of sync until the application ends or a later breakpoint is hit. 0x7c91eaf0 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf0 ntdll!LdrDisableThreadCalloutsForDll+4: mov(%esp),%ebx (gdb) 0x7c91eaf3 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf3 ntdll!LdrDisableThreadCalloutsForDll+7: push %ecx (gdb) 0x7c91eaf4 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf4 ntdll!LdrDisableThreadCalloutsForDll+8: push %ebx (gdb) 0x7c91eaf5 in ntdll!LdrDisableThreadCalloutsForDll () from /c/WINDOWS/system32/ntdll.dll 1: x/i $eip 0x7c91eaf5 ntdll!LdrDisableThreadCalloutsForDll+9: call 0x7c9477c1 ntdll!LdrFindCreateProcessManifest+424 (gdb) Program exited normally. (gdb) Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEeKSToHh+5t8EXncRAgxiAJsHfqsBSME06zaSaMD/kgrQH4GJAgCeMqUp wSedYnMrgNRpkpXRuny/2YE= =1zgp -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent schrieb:
[ I realized that a couple of points in this thread were never addressed -- we
sort of got side tracked on the GDB issue. I just want to reply to these
points
and try to convince you that this bug you see does not exist. People have a
tendency to point to the archives and say lookee, it's broken if the thread
does not come to a result. ]
Ralf Habacker wrote:
You said that the testcase runs, yes, but do you have tried to debug the
cygwin dll with this exception handling. Please start the above
mentioned testcase in gdb and enter
b main
r
b pthread_mutexattr::pthread_mutexattr()
c
This breakpoint is never reached (at least in released gdb) and makes it
hard to debug cygwin's threading stuff, probably impossible in this area.
The breakpoint does not fire, correct. But that is because
pthread_mutexattr's
constructor is empty (other than the initialization list):
pthread_mutexattr::pthread_mutexattr ():verifyable_object
(PTHREAD_MUTEXATTR_MAGIC),
pshared (PTHREAD_PROCESS_PRIVATE), mutextype (PTHREAD_MUTEX_ERRORCHECK)
{
}
If instead you set a breakpoint for the desired line that calls the
constructor
(in this case, thread.cc:3027) then it does fire.
If you take a look on assembler level you will find two constructors and
the breakpoint is set to the wrong one
0x610ad520 _ZN17pthread_mutexattrC2Ev+0: push %ebp
0x610ad560 _ZN17pthread_mutexattrC1Ev+0: push %ebp
(gdb) b pthread_mutexattr::pthread_mutexattr()
Breakpoint 3 at 0x610ad52c: - _ZN17pthread_mutexattrC2Ev
but called is the other one.
0x610b0f7b pthread_mutexattr_init+123:mov%eax,(%esp)
0x610b0f7e pthread_mutexattr_init+126:mov%eax,%ebx
0x610b0f80 pthread_mutexattr_init+128:call 0x610ad560
_ZN17pthread_mutexattrC1Ev
And if you use a CVS GDB you get no spurious faults either.
This means to be able to debug the cygwin dll in this area I have to
recompile a special cygwin version with something like below mentioned.:
/* FIXME: write and test process shared mutex's. */
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
old:
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
new:
if (attr pthread_mutexattr::is_good_object (attr))
return EBUSY;
This is totally useless. In order for if (attr) to be false, the function
would have had to been called as pthread_mutexattr_init (NULL) rather than
pthread_mutexattr_init (some_as_yet_uninitialized_variable). Furthermore, if
attr really were false, then the next line:
*attr = new pthread_mutexattr ();
would cause a NULL dereference which would not be caught, causing the program
to
crash and burn. The function must always be passed a valid pointer; the thing
it points to might be uninitialized though.
Let's walk through the complete series of events that happens in the testcase
below:
pthread_mutexattr_t mxAttr;
assert(pthread_mutexattr_init(mxAttr) == 0);
This is the thing that you claim is broken, however if you run this testcase
from a regular prompt (outside GDB) it does not assert, and in fact the
mutexattr is correctly initialized. (And if you do run it in a recent GDB it
does not assert nor fault either.)
Let's look at the entire chain of code involved here:
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
{
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
*attr = new pthread_mutexattr ();
if (!pthread_mutexattr::is_good_object (attr))
{
delete (*attr);
*attr = NULL;
return ENOMEM;
}
return 0;
}
inline bool
pthread_mutexattr::is_good_object (pthread_mutexattr_t const * attr)
{
if (verifyable_object_isvalid (attr, PTHREAD_MUTEXATTR_MAGIC) !=
VALID_OBJECT)
return false;
return true;
}
static inline verifyable_object_state
verifyable_object_isvalid (void const * objectptr, long magic, void
*static_ptr1, void *static_ptr2, void *static_ptr3)
{
verifyable_object **object = (verifyable_object **) objectptr;
myfault efault;
if (efault.faulted ())
return INVALID_OBJECT;
if ((static_ptr1 *object == static_ptr1) ||
(static_ptr2 *object == static_ptr2) ||
(static_ptr3 *object == static_ptr3))
return VALID_STATIC_OBJECT;
if ((*object)-magic != magic)
return INVALID_OBJECT;
return VALID_OBJECT;
}
So, the call chain will look like this:
pthread_mutexattr_init(mxAttr) -
pthread_mutexattr::is_good_object (mxAttr) -
verifyable_object_isvalid (mxAttr, PTHREAD_MUTEXATTR_MAGIC, NULL,NULL,NULL)
Of course, these last two functions will be expanded inline, so this will all
occur in the context of pthread_mutexattr_init. We are at the point in
verifyable_object_isvalid of:
if ((*object)-magic != magic)
Here, object is mxAttr, so
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor schrieb:
On Tue, May 23, 2006 at 09:20:28PM +0200, Ralf Habacker wrote:
your right, hope the above mentioned stuff help for this.
Ralf,
You have the test case. You have the source code. You've already
provided a patch. What's stopping you from determinging the cause of
the problem now that you understand that this situation is already
supposed to be handled? I appreciate that you have tracked this down
but I don't understand why you now seem to have given up at this point.
Have I said this ? I only reported about the current state in the hope
someone where bitten by the same issue and had some additional hints,
which seems not the case.
Anyway, the problem is that in
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
{
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
*attr = new pthread_mutexattr ();
pthread_mutexattr::is_good_object() is called, but attr does not contain
a valid object (it is created later) and the functions aborts, which
should not be.
Is there a replacement for the gone check_valid_pointer() function,
which could be added to pthread_mutexattr_init and was used before the
call to pthread_mutexattr::is_good_object() was introduced
(http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00204.html) ?
BTW: A similar problem is with
pthread_condattr_init ()
pthread_rwlockattr_init ()
pthread_attr_init ()
Regards
Ralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEdB/IoHh+5t8EXncRAsD/AJ9n/X9jLNaq0qoU2nFmpJpFLkks9QCeMJDM
a16WqHXFx0EjPu7HA+ORhKI=
=gRfG
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent schrieb: Ralf Habacker wrote: Running this testcase results in an internal exception in pthread_mutexattr_init() Program received signal SIGSEGV, Segmentation fault. 0x610b1005 in pthread_mutexattr_init (attr=0x404040) at ../../../../src/winsup/cygwin/thread.cc:129 129 if ((*object)-magic != magic) Sigh. We've been through this ad nauseum in the archives. This is how it's supposed to work, there's nothing wrong here. But in the case of pthread_mutexattr_init() this exception results in an abort of pthread_mutexattr_init(), which should not be. See my other mail in this thread. Gdb doesn't know any better though, and reports it as a SIGSEGV, when it is not. Did you not notice that when you run the program outside of the debugger it does not fault? There is no segfault, but it does not work as expected e.g. pthread_mutexattr_init() does not fill the pthread_mutexattr_t struct given as parameter. If you use a recent Cygwin snapshot and a gdb built from CVS you see no such fault, because this defect in gdb has been fixed. Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdCDRoHh+5t8EXncRAkcSAJ0TpZMnh5qhSQKY8nrb688Pq4bxogCfaTG5 9LDqWxCYGtlpmm9LBrKZcac= =2syh -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent schrieb:
Ralf Habacker wrote:
There is no segfault, but it does not work as expected e.g.
pthread_mutexattr_init() does not fill the pthread_mutexattr_t struct
given as parameter.
How does it not work? The testcase runs fine for me with no assertion
failures, neither from a prompt nor in (CVS) gdb. Even when I modify it
as follows:
--- pthread_mutexattr_init.c2006-05-24 02:05:52.523968000 -0700
+++ pthread_mutexattr_init_2.c 2006-05-24 02:11:27.299406200 -0700
@@ -9,6 +9,9 @@ main()
{
assert(pthread_mutexattr_init(mxAttr) == 0);
assert(pthread_mutexattr_settype(mxAttr, PTHREAD_MUTEX_ERRORCHECK)
== 0);
+ int t;
+ pthread_mutexattr_gettype(mxAttr, t);
+ assert(t == PTHREAD_MUTEX_ERRORCHECK);
assert(mutex == NULL);
assert(pthread_mutex_init(mutex, mxAttr) == 0);
assert(mutex != NULL);
...it still runs without failure.
BTW the whole myfault thing was devised specifically to kill the
IsBadReadPtr() junk that was used before, so asking for that back is
probably never going to happen. And with good reason too, because when
you call IsBadReadPtr is does exactly what myfault does, it installs a
temporary fault handler, tries to read the memory, and then removes that
temporary fault handler. Except that if you call IsBadReadPtr a bunch
of times it has to do this setup/teardown every time, instead of just
doing it once for the entire lexical scope of the function, as with
myfault.
Thanks for this info to understand the new exception handling in cygwin.
I was bitten last year by some thread relating problems while porting
qt3 to cygwin and had investigated some time to understand this stuff,
which has changed much in the meantime.
And yes, it used to be that gdb was too dumb to recognise that these
faults in IsBadReadPtr were not actual faults, and it would print them
as spurious SIGSEGVs, just as it currently does for myfaults. Then it
was patched to ignore faults in kernel32.dll. Now that the handler is
in cygwin1.dll, it had to be taught to ignore faults there too, and if
you use a CVS GDB, it does.
You said that the testcase runs, yes, but do you have tried to debug the
cygwin dll with this exception handling. Please start the above
mentioned testcase in gdb and enter
b main
r
b pthread_mutexattr::pthread_mutexattr()
c
This breakpoint is never reached (at least in released gdb) and makes it
hard to debug cygwin's threading stuff, probably impossible in this area.
This means to be able to debug the cygwin dll in this area I have to
recompile a special cygwin version with something like below mentioned.:
/* FIXME: write and test process shared mutex's. */
extern C int
pthread_mutexattr_init (pthread_mutexattr_t *attr)
old:
if (pthread_mutexattr::is_good_object (attr))
return EBUSY;
new:
if (attr pthread_mutexattr::is_good_object (attr))
return EBUSY;
BTW: This is not to hurt anyone or to bring in miscredit anyones work.
We all try our best to make cygwin as good as possible. It is only that
in this area things could be done better :-)
Regards
Ralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEdE8ooHh+5t8EXncRAhnRAKCfbhfNKawy70+t18zk56M3WHzuLACeJR1C
2WLX0BBt5N7efXQWuav0tNk=
=xZn9
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Habacker schrieb: Hi all, If this would be my project I would add such unit test cases as far as possible. Because pthread-win32 is also hosted on sources.redhat.com it may be possible to relicense the test application to cygwin easier as other external sources. No need for this, the related pthread functions are already in the cvs dir. See src/winsup/testsuite Running /home/Habacker/src/extern/cygwin.com/src/winsup/testsuite/winsup.api/cygload.exp ... FAIL: cygload (execute) Running /home/Habacker/src/extern/cygwin.com/src/winsup/testsuite/winsup.api/winsup.exp ... FAIL: msgtest.c (execute) FAIL: resethand.c (execute) FAIL: semtest.c (execute) FAIL: shmtest.c (execute) === winsup Summary === # of expected passes270 # of unexpected failures5 # of expected failures 8 Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdH0GoHh+5t8EXncRAoesAJ4gHbZ2OKdciNcj/9sChnAkKAP7RwCeM/XW t2kzO62zKpUx4KoNtareNVQ= =5g6q -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian Dessent schrieb: Ralf Habacker wrote: And yes, it used to be that gdb was too dumb to recognise that these faults in IsBadReadPtr were not actual faults, and it would print them as spurious SIGSEGVs, just as it currently does for myfaults. Then it was patched to ignore faults in kernel32.dll. Now that the handler is in cygwin1.dll, it had to be taught to ignore faults there too, and if you use a CVS GDB, it does. This kind of exceptions are handled complete in cygwin itself. Is there no way to limit this exceptions to the cygwin library itself and to hide them to the rest ? This way exceptions are handled looks to me like a specific implementation detail, which will worry users more than that it helps to find problems in an application. And what about debugging cygwin itself ? It looks to me that disabling of this exception handling code must be possible ? You may say to, this has to be done by gdb, but what about strace ? Do I need to run strace through gdb to avoid such exception messages ? Or will strace be patched too to hide such messages ? Remember the previously listed examples where those messages occupies about 70% of the whole output of an straced application. Because this exception addresses are located in the cygwin dll it will produce many, many obsolate support requests to the cygwin mailing list (as I was faced) and will stresses the support people instead that they can give support for the real problems and will eat time from the developer. And what about the usage of other windows debuggers ? Does they have also such specific exception hiding support ? If not will there be a manual how to disable this internal messages ? As summary, I don't think that patching gdb is the best solution. It would be better to limit these exception to the cygwin dll and to hide this message to the rest. May be an option in the cygwin or other environment var to enable such message for debugging purpose will be useful. Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEdIYToHh+5t8EXncRAjT8AJ4tnrVX6EDj5rynw8MPgd5TXAWeBwCfXVrU wogfOq23tMiXfHoUTKorKR8= =J6R+ -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
It would appear that changes to the cygwin1.dll since 1.5.18-1 (and
before the 20051207 snapshot) have broken Qt3. The relevant threads
until now:
It looks that this problem is not limited to qt3 because the following
simple test applications taken from the pthread-win32 packages
ftp://sources.redhat.com/pub/pthreads-win32/pthreads-snap-2005-03-08.tar.gz
results into a seg fault.
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex1b | grep C005
strace: error creating process mutex1b, (error 2)
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex1n | grep C005
- --- Process 4872, exception C005 at 610B1005
155 78759 [main] mutex1n 4872 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CC00
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex1r | grep C005
- --- Process 4960, exception C005 at 610B1005
153 40208 [main] mutex1r 4960 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CC00
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace mutex2
| grep C005
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace mutex6
| grep C005
Assertion failed: (pthread_mutex_lock(mutex) == 0), file mutex6.c, line 59
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex6n | grep C005
- --- Process 4820, exception C005 at 610B1005
174 17751 [main] mutex6n 4820 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CBF0
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex6r | grep C005
- --- Process 5676, exception C005 at 610B1005
182 12533 [main] mutex6r 5676 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CBF0
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex6s | grep C005
Assertion failed: (pthread_mutex_lock(mutex) == 0), file mutex6s.c, line 59
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex7r | grep C005
- --- Process 6240, exception C005 at 610B1005
174 28939 [main] mutex7r 6240 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CBF0
I identified the problem to the function pthread_mutexattr_init address
0x610b1005 in which a null pointer (%eax below) causes this seg faults
0x610b1003 pthread_mutexattr_init+259: mov(%edi),%eax
0x610b1005 pthread_mutexattr_init+261: cmpl $0xdf0df049,0x4(%eax)
0x610b100c pthread_mutexattr_init+268: je 0x610b1070
pthread_mutexattr_init+368
The relating source code is in thread.cc inline function
verifyable_object_isvalid():
...
if ((*object)-magic != magic)
return INVALID_OBJECT;
The problem is that if *object is zero the access to the magic element
fails.
The following patch catch this zero pointer, although I'm not sure if
this zero pointer indicates a major fault conditions in the threading stuff
Changelog:
2006-05-23 Ralf Habacker [EMAIL PROTECTED]
* thread.cc (verifyable_object_isvalid): catch zero pointer.
Index: thread.cc
===
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
retrieving revision 1.198
diff -u -b -B -r1.198 thread.cc
- --- thread.cc 22 Mar 2006 20:38:26 - 1.198
+++ thread.cc 23 May 2006 13:16:57 -
@@ -118,6 +118,9 @@
{
verifyable_object **object = (verifyable_object **) objectptr;
+ if (*object == NULL)
+return INVALID_OBJECT;
+
myfault efault;
if (efault.faulted ())
return INVALID_OBJECT;
After some more investigation I found that there are additional cases
where seg faults happens because of object pointer not being null and
not be valid. This needs more research.
BTW: Using the pthread test applications makes it much easier to check
the threading api. For example there is an unhandled case in
semaphore::_timedwait where abstime=NULL results into seg fault.
If this would be my project I would add such unit test cases as far as
possible. Because pthread-win32 is also hosted on sources.redhat.com it
may be possible to relicense the test application to cygwin easier as
other external sources.
If wished, I can help adding some of these test applications.
Regards
Ralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEc0HwoHh+5t8EXncRAkXvAJ93oYvQOcPWc0jvLpoFj4lBFUDVxACcCdAc
HXNcHvvAF+is8L//ADQMGi0=
=wQG1
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Korn schrieb: On 23 May 2006 18:10, Ralf Habacker wrote: Oh no, not this old saw again! C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace mutex1n | grep C005 - --- Process 4872, exception C005 at 610B1005 155 78759 [main] mutex1n 4872 _cygtls::handle_exceptions: In cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CC00 [ snip many more ]. I identified the problem to the function pthread_mutexattr_init address 0x610b1005 in which a null pointer (%eax below) causes this seg fault Yes, but it's wrapped in an exception handler. That's why you get to see an strace error message, rather than having the process exit. Names like cygwin_except_handler and _cygtls::handle_exceptions should have given you some clues about this Hmmh, I have learned to fix obviously problems instead let it handle by an exception handler, which has several disadvantages. 1. It costs additional runtime. In the mentioned designer i count 1653 internal exceptions, which are caused by the null pointer issue. 2. 70% of my strace output (1000 lines) are polluted by this internal exceptions messages, which could be avoided by changing only on lines of code. Do you think that this is the effort worth ? Are there more problems with this simple patch ? Regards Ralf -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEc1DEoHh+5t8EXncRArlMAJ9epXvjle2JEMHKawUbLTndwtMRMwCfY2+D v0dV1EFxuvjvUJKzhfDZJTE= =hHTj -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.5.19: changes have broken Qt3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher Faylor schrieb:
On Tue, May 23, 2006 at 08:13:24PM +0200, Ralf Habacker wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Korn schrieb:
On 23 May 2006 18:10, Ralf Habacker wrote:
Oh no, not this old saw again!
C:\cygwin\home\Habacker\src\pthreads-snap-2005-03-08\testsstrace
mutex1n | grep C005
- --- Process 4872, exception C005 at 610B1005
155 78759 [main] mutex1n 4872 _cygtls::handle_exceptions: In
cygwin_except_handler exc 0xC005 at 0x610B1005 sp 0x22CC00
[ snip many more ].
I identified the problem to the function pthread_mutexattr_init address
0x610b1005 in which a null pointer (%eax below) causes this seg fault
Yes, but it's wrapped in an exception handler. That's why you get to see
an
strace error message, rather than having the process exit. Names like
cygwin_except_handler and _cygtls::handle_exceptions should have given
you
some clues about this
Hmmh, I have learned to fix obviously problems instead let it handle by
an exception handler, which has several disadvantages.
1. It costs additional runtime. In the mentioned designer i count 1653
internal exceptions, which are caused by the null pointer issue.
2. 70% of my strace output (1000 lines) are polluted by this internal
exceptions messages, which could be avoided by changing only on lines of
code. Do you think that this is the effort worth ?
Are there more problems with this simple patch ?
The obvious problem is that you have provided an analysis of the common
code path. If the standard code path does not usually involve a NULL
pointer then your patch introduces a statistically unneeded test, i.e.,
in your test case there are NNN internal exceptions but you haven't
stated that your test case is the standard way that these functions
would be used.
Okay, here is one of the test cases. Can anyone confirm, that this is a
standard way ?
#include assert.h
#include pthread.h
pthread_mutex_t mutex = NULL;
pthread_mutexattr_t mxAttr;
int
main()
{
assert(pthread_mutexattr_init(mxAttr) == 0);
assert(pthread_mutexattr_settype(mxAttr, PTHREAD_MUTEX_ERRORCHECK) == 0);
assert(mutex == NULL);
assert(pthread_mutex_init(mutex, mxAttr) == 0);
assert(mutex != NULL);
assert(pthread_mutex_lock(mutex) == 0);
assert(pthread_mutex_unlock(mutex) == 0);
assert(pthread_mutex_destroy(mutex) == 0);
assert(mutex == NULL);
return 0;
}
Running this testcase results in an internal exception in
pthread_mutexattr_init()
Program received signal SIGSEGV, Segmentation fault.
0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
../../../../src/winsup/cygwin/thread.cc:129
129 if ((*object)-magic != magic)
1: x/i $eip 0x610b1005 pthread_mutexattr_init+261: cmpl
$0xdf0df049,0x4(%eax)
the variable object is located in eax, which is zero.
(gdb) p $eax
$1 = 0
There are two threads
(gdb) info thread
2 thread 5772.0x1abc 0x7c91eb94 in ntdll!LdrAccessResource () from
ntdll.dll
* 1 thread 5772.0xc50 0x610b1005 in pthread_mutexattr_init
(attr=0x404040) at ../../../../src/winsup/cygwin/thread.cc:129
and the backtrace say that pthread_mutexattr_init() is called by _sigfe
(gdb) bt
#0 0x610b1005 in pthread_mutexattr_init (attr=0x404040) at
../../../../src/winsup/cygwin/thread.cc:129
#1 0x61090d68 in _sigfe () at ../../../../src/winsup/cygwin/cygserver.h:82
#2 0x00401050 in mainCRTStartup ()
(gdb)
but this backtrace save only that this functions seems to called from
the signal thread.
If the standard code path involves non-NULL pointers
then adding your test would mean a net slowdown.
Also, since the current code is supposed to deal with the problem
without your patch, your patch can't be considered as anything other
than a band-aid until the reason for the problem is actually understood.
your right, hope the above mentioned stuff help for this.
Ralf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEc2B8oHh+5t8EXncRAlVrAJoDPcvJb/ynI6T+m4jtiUwxTlweQwCgoD6k
nEtFHGFWiE3j0SaMBUgCVRE=
=gRS1
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: setup alternatives
Am Mittwoch, 22. Juni 2005 18:27 schrieb Brian Dessent: Jason Pyeron wrote: static link and boot strap a core with the installer. Just like installing linux from cd. Cygwin1.dll cannot be statically linked. gosh darnit, I just want to upgrade cygwin via ssh. You can try the 'cygupdate' tools in CVS. I haven't heard about this before. Another script based solution could be found under http://cvs.sourceforge.net/viewcvs.py/kde-cygwin/tools/cygsetup/. In our company we uses this script for about one year without any major problems (except the dll in use problem). If wished I can provide a setup confirm package. Ralf Habacker -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Serious performance problems (malloc related?)
Am Donnerstag, 2. Juni 2005 23:43 schrieb Keith Moore: Igor Pechtchanski wrote: Dropping it altogether would be unfortunate. Providing Win98 support DLLs in a separate package is a possibility. There's still the point that CGF raised, about there being many more people with the knowledge of Win32 API than those with the knowledge of Nt* API. Is there anything I can do to help with the Nt* conversion? I've been using the native NT APIs for about 15 years. I'm not so familiar with the APIs added in WinXP and 2003, but I'm *very* familiar with the core API set. There were several attempts and many discussions in the past to speed up the fork implementation but unfortunally without any succes. Maybe using the NT api could help in this area. I found one thread indicating this as possible solution in http://www.osronline.com/lists_archive/ntdev/thread4267.html Ralf I have recently received my official anoitment from Redhat so I can officially contribute to Cygwin. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Serious performance problems (new snapshot has some performance improvement)
Am Dienstag, 31. Mai 2005 12:05 schrieb Gerrit P. Haase: [EMAIL PROTECTED] wrote: Am Montag, 30. Mai 2005 22:33 schrieb Gerrit P. Haase: Anonymous wrote: My System: #Set-up: $ g++ cygspd.cc -o cygspd-basic $ g++ -O7 cygspd.cc -o cygspd-o7 $ g++ -fno-exceptions cygspd.cc -o cygspd-ne $ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7 $ g++ -mno-cygwin cygspd.cc -o cygspd-mingw $ g++ -O7 -mno-cygwin cygspd.cc -o cygspd-mingw-o7 $ g++ -fno-exceptions -mno-cygwin cygspd.cc -o cygspd-mingw-ne $ g++ -O7 -fno-exceptions -mno-cygwin cygspd.cc -o cygspd-mingw-ne-o7 # cygwin.dll 1.5.17 [...] $ /bin/time -f %E %S %U cygspd-mingw cygspd.dat 0:03.11 0.00 0.02 $ /bin/time -f %E %S %U cygspd-mingw-o7 cygspd.dat 0:01.50 0.01 0.02 $ /bin/time -f %E %S %U cygspd-mingw-ne cygspd.dat 0:02.60 0.00 0.02 $ /bin/time -f %E %S %U cygspd-mingw-ne-o7 cygspd.dat 0:01.50 0.01 0.01 #Snapshot DLL (No changes were made except swapping the dll. [...] $ /bin/time -f %E %S %U cygspd-mingw cygspd.dat 0:02.78 0.00 0.01 $ /bin/time -f %E %S %U cygspd-mingw-o7 cygspd.dat 0:01.51 0.01 0.01 $ /bin/time -f %E %S %U cygspd-mingw-ne cygspd.dat 0:02.52 0.00 0.02 $ /bin/time -f %E %S %U cygspd-mingw-ne-o7 cygspd.dat 0:01.45 0.00 0.01 Interesting, why is it faster when running a binary that doesn't depend on cygwin1.dll after swapping the DLL? Some Win caching mechanism? I recognized this caching behavior with KDE/cygwin too. Under http://cvs.sourceforge.net/viewcvs.py/kde-cygwin/tools/fillmem/ there is a tool, which could be used to minimize this influcence by clearing this cache. See the README for more informations. GlobalMemoryStatusEx is only available on Win2k and WinXP. Does anyone know a similar function under win9x ? Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Serious performance problems (new snapshot has some performance improvement)
Am Dienstag, 31. Mai 2005 12:42 schrieb Gerrit P. Haase: Ralf Habacker wrote: Interesting, why is it faster when running a binary that doesn't depend on cygwin1.dll after swapping the DLL? Some Win caching mechanism? I recognized this caching behavior with KDE/cygwin too. Under http://cvs.sourceforge.net/viewcvs.py/kde-cygwin/tools/fillmem/ there is a tool, which could be used to minimize this influcence by clearing this cache. See the README for more informations. GlobalMemoryStatusEx is only available on Win2k and WinXP. Does anyone know a similar function under win9x ? Danny Smith wrote a replacement: http://gcc.gnu.org/ml/gcc-patches/2003-02/msg02045.html Thanks for this pointer. I've incorporated this function into fillmem. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Serious performance problems (new snapshot has some performance improvement)
Am Montag, 30. Mai 2005 22:33 schrieb Gerrit P. Haase: Anonymous wrote: My System: #Set-up: $ g++ cygspd.cc -o cygspd-basic $ g++ -O7 cygspd.cc -o cygspd-o7 $ g++ -fno-exceptions cygspd.cc -o cygspd-ne $ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7 $ g++ -mno-cygwin cygspd.cc -o cygspd-mingw $ g++ -O7 -mno-cygwin cygspd.cc -o cygspd-mingw-o7 $ g++ -fno-exceptions -mno-cygwin cygspd.cc -o cygspd-mingw-ne $ g++ -O7 -fno-exceptions -mno-cygwin cygspd.cc -o cygspd-mingw-ne-o7 # cygwin.dll 1.5.17 [...] $ /bin/time -f %E %S %U cygspd-mingw cygspd.dat 0:03.11 0.00 0.02 $ /bin/time -f %E %S %U cygspd-mingw-o7 cygspd.dat 0:01.50 0.01 0.02 $ /bin/time -f %E %S %U cygspd-mingw-ne cygspd.dat 0:02.60 0.00 0.02 $ /bin/time -f %E %S %U cygspd-mingw-ne-o7 cygspd.dat 0:01.50 0.01 0.01 #Snapshot DLL (No changes were made except swapping the dll. [...] $ /bin/time -f %E %S %U cygspd-mingw cygspd.dat 0:02.78 0.00 0.01 $ /bin/time -f %E %S %U cygspd-mingw-o7 cygspd.dat 0:01.51 0.01 0.01 $ /bin/time -f %E %S %U cygspd-mingw-ne cygspd.dat 0:02.52 0.00 0.02 $ /bin/time -f %E %S %U cygspd-mingw-ne-o7 cygspd.dat 0:01.45 0.00 0.01 Interesting, why is it faster when running a binary that doesn't depend on cygwin1.dll after swapping the DLL? Some Win caching mechanism? I recognized this caching behavior with KDE/cygwin too. Under http://cvs.sourceforge.net/viewcvs.py/kde-cygwin/tools/fillmem/ there is a tool, which could be used to minimize this influcence by clearing this cache. See the README for more informations. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Rebase dlls not from cygwin
Am Dienstag, 24. Mai 2005 13:47 schrieb Jason Tishler: Hermann, On Mon, May 23, 2005 at 11:06:29PM +0200, Hermann Klocker wrote: Sorry if I email directly to you - I am new to cygwin. Please tell me if I should have posted this report to another location. I would have preferred if you posted to the Cygwin mailing list instead of sending private email. I think I have a problem similar to a posting I found regarding rebase failing with message not rebaseable. I try to run Dakota 3.3 (from http://endo.sandia.gov/DAKOTA/licensing/release/Dakota_3_3.cygwin.tar.gz) with cygwin 1.5.16. When trying to start Dakota I get the error message $ dakota 1723 [main] ? 5132 cygheap_fixup_in_child: Couldn't reserve 9891792 bytes of space for cygwin's heap (0x6181 0x15C) in child, Win32 error 487 C:\cygwin\usr\local\bin\dakota.exe (5132): *** m.AllocationBase 0x0, m.BaseAddre ss 0x6181, m.RegionSize 0x5B, m.State 0x1 I recognized this type of problems with kde on cygwin too, when dll's are rebased into the address area immediatly above the cygwin1.dll. I fixed this problems using the rebase base address option -b e.g. rebase -b 0x6100 ... Ralf After all I have read about this message I thougt rebase should solve my problem, alas trying to rebase all dlls from Dakota (these are the only ones residing in /usr/local/bin) gave: $ cat list1 /usr/local/bin/mpich.dll /usr/local/bin/mpichd.dll /usr/local/bin/mpicherr.dll /usr/local/bin/PHXCppApi.dll [EMAIL PROTECTED] /usr/local/bin $ rebaseall -T list1 -v rb.out /usr/bin/tclpip84.dll: skipped because not rebaseable /usr/local/bin/mpich.dll: skipped because not rebaseable /usr/local/bin/mpichd.dll: skipped because not rebaseable /usr/local/bin/mpicherr.dll: skipped because not rebaseable /usr/local/bin/PHXCppApi.dll: skipped because not rebaseable Do you have any hints regarding this problem? At the moment no. However, I was able to reproduce the above. I will enhance rebase to indicated why it thinks a DLL is not rebaseable when the verbose option is specified. Although this change may produce better diagnostics, it may not solve your problem. Note that some DLLs are just not rebaseable -- for example, tclpip84.dll. Jason -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re:cygwin, libtool, dlpreopen, and .rdata
Hi Chuck,
you wrote
With newer gcc's (cygwin version numbers 3.3.3-3, 3.4.1-1, but not 3.3.1-3),
const variables are placed in an .rdata section. This causes problems when
those variables contain references to OTHER vars that are imported from a
dll -- because the runtime relocation machinery can't fixup the address,
since the variable holding the address is const -- and is in .rdata!
snip
But it can't, because .rdata is non-writable. However, this is a *runtime*
error; the *link* succeeds. But when you run the app, you get a popup window
declaring:
The application failed to initialize properly (0xc005). Click on OK to
terminate the application.
Note that (1) the nothing relocation works fine for normal links;
hell.exe works ok, and imports nothing correctly.
snip
*
I see two solutions: a short term libtool-focused workaround,
and a longer term general solution.
stumpled the last time about this problem with qt/cygwin releases and found a
generic workaround by using a specific linker script, which avoids rdata
sections. (script is appended).
Copy the linker script for example to /usr/lib/ldscripts and run the following
line to link a dll.
gcc -Wl,--script,/usr/lib/ldscripts/i386pe.x-no-rdata
May be this help some people
Regards
Ralf
/* specific linker script avoiding .rdata sections, for normal executables
for a reference see
http://www.cygwin.com/ml/cygwin/2004-09/msg01101.html
http://www.cygwin.com/ml/cygwin-apps/2004-09/msg00309.html
*/
OUTPUT_FORMAT(pei-i386)
SEARCH_DIR(/usr/i686-pc-cygwin/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/lib/w32api);
ENTRY(_mainCRTStartup)
SECTIONS
{
.text __image_base__ + __section_alignment__ :
{
*(.init)
*(.text)
*(SORT(.text$*))
*(.glue_7t)
*(.glue_7)
___CTOR_LIST__ = .; __CTOR_LIST__ = . ;
LONG (-1);*(.ctors); *(.ctor); *(SORT(.ctors.*)); LONG (0);
___DTOR_LIST__ = .; __DTOR_LIST__ = . ;
LONG (-1); *(.dtors); *(.dtor); *(SORT(.dtors.*)); LONG (0);
*(.fini)
/* ??? Why is .gcc_exc here? */
*(.gcc_exc)
PROVIDE (etext = .);
*(.gcc_except_table)
}
/* The Cygwin32 library uses a section to avoid copying certain data
on fork. This used to be named .data. The linker used
to include this between __data_start__ and __data_end__, but that
breaks building the cygwin32 dll. Instead, we name the section
.data_cygwin_nocopy and explictly include it after __data_end__. */
.data BLOCK(__section_alignment__) :
{
__data_start__ = . ;
*(.data)
*(.data2)
*(SORT(.data$*))
*(.rdata)
*(SORT(.rdata$*))
*(.eh_frame)
___RUNTIME_PSEUDO_RELOC_LIST__ = .;
__RUNTIME_PSEUDO_RELOC_LIST__ = .;
*(.rdata_runtime_pseudo_reloc)
___RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
__RUNTIME_PSEUDO_RELOC_LIST_END__ = .;
__data_end__ = . ;
*(.data_cygwin_nocopy)
}
.rdata BLOCK(__section_alignment__) :
{
}
.pdata BLOCK(__section_alignment__) :
{
*(.pdata)
}
.bss BLOCK(__section_alignment__) :
{
__bss_start__ = . ;
*(.bss)
*(COMMON)
__bss_end__ = . ;
}
.edata BLOCK(__section_alignment__) :
{
*(.edata)
}
/DISCARD/ :
{
*(.debug$S)
*(.debug$T)
*(.debug$F)
*(.drectve)
}
.idata BLOCK(__section_alignment__) :
{
/* This cannot currently be handled with grouped sections.
See pe.em:sort_sections. */
SORT(*)(.idata$2)
SORT(*)(.idata$3)
/* These zeroes mark the end of the import list. */
LONG (0); LONG (0); LONG (0); LONG (0); LONG (0);
SORT(*)(.idata$4)
SORT(*)(.idata$5)
SORT(*)(.idata$6)
SORT(*)(.idata$7)
}
.CRT BLOCK(__section_alignment__) :
{
___crt_xc_start__ = . ;
*(SORT(.CRT$XC*)) /* C initialization */
___crt_xc_end__ = . ;
___crt_xi_start__ = . ;
*(SORT(.CRT$XI*)) /* C++ initialization */
___crt_xi_end__ = . ;
___crt_xl_start__ = . ;
*(SORT(.CRT$XL*)) /* TLS callbacks */
/* ___crt_xl_end__ is defined in the TLS Directory support code */
___crt_xp_start__ = . ;
*(SORT(.CRT$XP*)) /* Pre-termination */
___crt_xp_end__ = . ;
___crt_xt_start__ = . ;
*(SORT(.CRT$XT*)) /* Termination */
___crt_xt_end__ = . ;
}
.tls BLOCK(__section_alignment__) :
{
___tls_start__ = . ;
*(.tls)
*(.tls$)
*(SORT(.tls$*))
___tls_end__ = . ;
}
.endjunk BLOCK(__section_alignment__) :
{
/* end is deprecated, don't use it */
PROVIDE (end = .);
PROVIDE ( _end = .);
__end__ = .;
}
.rsrc BLOCK(__section_alignment__) :
{
*(.rsrc)
*(SORT(.rsrc$*))
}
.reloc BLOCK(__section_alignment__) :
{
*(.reloc)
}
.stab BLOCK(__section_alignment__) (NOLOAD) :
{
*(.stab)
}
.stabstr BLOCK(__section_alignment__) (NOLOAD) :
{
*(.stabstr)
}
/* DWARF debug sections.
Symbols in the DWARF debugging sections are relative to the beginning
of the section. Unlike other
Re: can't start KDE on FreeBSD from Windows XP
On Tuesday 07 September 2004 10:36, Alexander Gottwald wrote: On Mon, 6 Sep 2004, Bruce Rhodewalt wrote: I'm having trouble configuring KDE on my Windows XP machine (using Cygwin/X 2004/03/25). From my bash shell, I can ssh or telnet to my FreeBSD 5.2.1 RELEASE machine. However, if I try to connect and run KDE, I have problems. where do you run KDE? On the FreeBSD box or on cygwin? The log below say you're starting it on cygwin. If so then I'd pass you on to the kde-cygwin mailing list. iceauth: creating new authority file /home/Bruce/.ICEauthority KDEINIT_KIO_EXEC kdeinit: Launched KLauncher, pid = 3604 result = 0 C:\programfiles\cygwin\opt\kde3\bin\kdeinit.exe (3872): *** unable to remap C:\p rogramfiles\cygwin\bin\cygz.dll to same address as parent(0xD3) != 0xD4 1105 [main] kdein 3604 sync_with_child: child 3872(0x65C) died before initi alization with status code 0x1 1632 [main] kdein 3604 sync_with_child: *** child state child loading dlls I think this is the reason why you get no windows. But i have no clue what caused this error. This is a rebasing problem. See http://kde-cygwin.sourceforge.net/kde3/faq.php#rebase. BTW: Don't know the email address of bruce so send to the cygwin-xfree list too. Regards Ralf
Re: kde3+cygwin startup problem
On Friday 30 April 2004 17:15, Nicholas Gibson wrote: I'm at a loss, this is a fresh install of cygwin+kde3 on a machine that has just been built with XP. There are no spaces in my home path, any help would be much appreciated. My kde session never gets past this point, it just sits there at starting window manager. snip kdeinit: Launched KLauncher, pid = 2620 result = 0 C:\cygwin\opt\kde3\bin\kdeinit.exe (2940): *** unable to remap C:\cygwin\bin\cygz.dll to same address as parent(0xD3) != 0xD4 3 [main] kdein 2620 sync_with_child: child 2940(0x690) died before initi alization with status code 0x1 318 [main] kdein 2620 sync_with_child: *** child state child loading dlls see http://kde-cygwin.sf.net/kde3/faq.php#rebase Ralf
Re: kde fails to start after clean install
On Monday 26 April 2004 22:51, Nicholas Gibson wrote: I am attempting to start kde after a fresh installation of cygwin and kde from http://kde-cygwin.sourcefroge.net. This is on a fresh machine with 1GB of RAM and plenty of disk space... It hangs at loading the window manager. I love kde on cygwin, any help would be much appreciated... snip kdeinit: Launched KLauncher, pid = 3920 result = 0 C:\cygwin\opt\kde3\bin\kdeinit.exe (2664): *** unable to remap C: \cygwin\bin\cygz.dll to same address as parent(0xD3) != 0xD4 This is a rebasing problem, see http://kde-cygwin.sourceforge.net/kde3/faq.php#rebase how to fix it. Ralf
Re: gentoo portage and cygwin
On Monday 19 April 2004 12:06, Thorsten Kampe wrote: * Sven Köhler (2004-04-19 07:58 +0100) has anybody ever tried to port the gentoo-portage to cygwin? not that i expect many of the gentoo-ebuilds to compile, but the cygwin-people could maintain their own portage. the gentoo-portage also supports binary packages so that you don't have to compile everything yourself. * portage-cygwin http://sourceforge.net/project/showfiles.php?group_id=27249package_id=1901 9release_id=199935 please note that this portage release depends on python-2.2. The initial porter hasn't updated it to python2.3 and we cannot give support for this package. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: proposal for using windows truetype fonts
On Thursday 01 April 2004 02:16, Igor Pechtchanski wrote: On Wed, 31 Mar 2004, Eric Hanchrow wrote: Ralf == Ralf Habacker [EMAIL PROTECTED] writes: Ralf # Create a symbolic link for the windows truetype fonts ln Ralf -sf $SYSTEMROOT/Fonts /usr/X11R6/lib/X11/fonts/truetype Is the environment variable SYSTEMROOT guaranteed to be defined? If not, you might be able to use WINDIR instead. Actually, it's better to use `cygpath -W` (or `cygpath -Ww` to get exactly the same value as $SYSTEMROOT). Igor SYSTEMROOT is only avaliable for winNT and above, not for win9x, so using $WINDIR or cygpath would be better. I've tried this and it works. The script should look like $ cat /etc/postinstall/freetype2.sh #!/bin/sh # Create a link to /usr/bin/freetype-config mkdir -p /usr/X11R6/bin ln -sf /usr/bin/freetype-config /usr/X11R6/bin/freetype-config # Create a symbolic link for the windows truetype fonts ln -sf $WINDIR/Fonts /usr/X11R6/lib/X11/fonts/truetype rsp. ln -sf `cygpath -Ww` /usr/X11R6/lib/X11/fonts/truetype Anywhay, relating to the the thread ttmkfdir no longer needed there may be an access problem in symlinking the original windows dir. My question now is: in which package this font handling stuff should go in the freetype package, an already xfree package like fonts or a new true type package ? Ralf
Re: ttmkfdir no longer needed
On Saturday 10 April 2004 03:09, Harold L Hunt II wrote: It looks like we no longer need ttmkfdir in order to expose the fonts installed with Windows to X11. The mkfontscale utility that is included with out distribution was inspired by ttmkfdir and essentially replaces it: http://freedesktop.org/~xorg/X11R6.7.0/doc/mkfontscale.1.html You can do something like the following right now (well, not with Cygwin 1.5.9 since mkfontscale will core dump, you have to use snapshot of cygwin1.dll for the moment): 1) mkfontscale /cygdrive/c/WINDOWS/Fonts 2) mkfontdir /cygdrive/c/WINDOWS/Fonts 3) Launch Cygwin/X 4) In a bash shell under Cygwin/X, run: xset fp+ /cygdrive/c/WINDOWS/Fonts 5) Run xfontsel and observe that picking 'microsoft' from the 'rgstry' category exposes 'microsoft sans serif', 'tahoma', and 'verdana' among others under the 'fmly' category. Note also that valid chartacters appear when you select these fonts. Due to this I am going to pull the link to ttmkfdir from our 'Ported Software' page. Perhaps someone would like to write a postinstall script that creates symlinks to the Fonts folder for Windows under /usr/X11R6/lib/X11/fonts/windows, then runs mkfontscale and mkfontdir in that folder (since we can not guarantee that we have permissions to create files in the actual Fonts folder for Windows). Then it would take a minor adjustment of our startup scripts to pass this additional font folder to Cygwin/X on startup. One note: In the thread proposal for using windows truetype fonts I suggested to use the /usr/X11R6/lib/X11/fonts/truetype dir for truetype fonts, because this is the default for qt and kde. Are there any objectivities using this instead of /usr/X11R6/lib/X11/fonts/windows ? Any takers? I'm not very a experted x user, so that I can check up if there is more work required, but as a start point this should work: #!/bin/sh ttfontdir=/usr/X11R6/lib/X11/fonts/windows # uncomment for enabling qt and kde like truetype font dir #ttfontdir=/usr/X11R6/lib/X11/fonts/truetype mkdir $ttfontdir lndir $WINDIR\\Fonts $ttfontdir mkfontscale $ttfontdir mkfontdir $ttfontdir btw. I've got one error while testing this $ mkfontscale /usr/X11R6/lib/X11/fonts/truetype Couldn't get family name for /usr/X11R6/lib/X11/fonts/truetype/MARLETT.TTF Does this give any problems ? I'll package it if somebody works the kinks out of it. for syn with the above mentioned thread - in which package this script will go - In the freetype, xfree font or a new package ? Ralf
Re: Gold stars for an anonymous contributor
On Friday 09 April 2004 02:58, Christopher Faylor wrote: You know how I always whine about how I can't debug 64 bit windows without a 64 bit system and have asked (not entirely seriously) for the contribution of a system? Well, I now have a brand new 64 bit windows system, contributed by an anonymous benefactor. Needless to say I was blown away by her generosity. In fact he impressed my whole family, who now is a step closer to understanding what I'm doing when I am typing on the computer and someone asks me if I'm working and I say Not really. I'm donating my time. So, I'd like to give ten gold stars to this anonymous benefactor. Her unbelievable generosity is truly appreciated. Nice to hear that this makes new things possible. After looking at the gold star list and for what the gold stars are given, I'm wondering why the initiator of the /proc interface is not listed. Just a question. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
proposal for using windows truetype fonts
Hi, currently I'm trying the xft stuff with windows true type fonts for cygwin/qt and kde applications and it works really good. I'm planning to release the next qt/kde releases with xft support enabled. One thing I have noticed, is that a symbolic link from the windows fonts dir is required into the X11 front root dir, so I added this link to the freetype2 postinstall script as seen below, because it looks to me as the best place to add. Any comments ? Ralf $ cat /etc/postinstall/freetype2.sh #!/bin/sh # Create a link to /usr/bin/freetype-config mkdir -p /usr/X11R6/bin ln -sf /usr/bin/freetype-config /usr/X11R6/bin/freetype-config # Create a symbolic link for the windows truetype fonts ln -sf $SYSTEMROOT/Fonts /usr/X11R6/lib/X11/fonts/truetype
Re: Changing jobs
On Wednesday 31 March 2004 20:08, Christopher Faylor wrote: I just wanted to send a brief note to inform everyone that today is my last day at Red Hat. I have accepted a position with TimeSys Corporation. I plan on continuing my volunteer work on both Cygwin and on sources.redhat.com so people here should see little change in that regard. Corinna Vinschen has volunteered to be the official Red Hat maintainer for Cygwin. So, she'll be involved with any special cygwin licensing issues (she gets all of the distasteful stuff). Corinna and I will be co-project leads for Cygwin. So, again, I don't think anyone will notice much of a change but I thought I should make my new situation clear. Anyway, this is a good moment to say thanks for your huge efforts. Without your work, kde-cygwin would not have been got off the ground. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
note on command line installer
Hi Robert, you may wondering about you haven't heard anything in the last months after I have offered some time working on the command line cygwin installer (for example http://sources.redhat.com/ml/cygwin-apps/2003-11/msg0.html) but there were some personal (at that time one of my sons has an arm fracture, which results in a week spend in a hospital and has eaten my preserved time for the installer) and other reasons for this. I appreciate your work on this installer very much and I'm using this installer still for kde-cygwin, but I recognized that with the current code base, implemeting a command line installer would costs too much time I don't have yet, so I'm not able to work on this now (this may be change in the future, but I can't see this at this time), but I like to give some report so that others, how may benefit from this work. The main problems with the recent code base I see are 1. the intermixing of gui and core functionality. You have written about a minimal way to implement new applications using all files in one directory, but this is one of the main problems. If someone implements a command line installer, he is only interested on the core stuff not the gui stuff. The intermixing makes it very hard to see what is gui and what is core, and probably gui and other patches will be applied on wrong places, which increases needed bug fixing efforts. 2. The high abstraction of the api. In the last two years I have analysed and patched some of the kde sources and I have recognized this as a relative easy task because of the very high clearness of this implementation. With the cygwin installer sources sometime I felt lost, which makes it very hard to understand, whats going on and where to patch. Because it seems to be a problem to separate the gui from the core in the current implementation, the easiest thing would be to start new from scratch by using all usable code and classes from the current implementation with a clear design. BTW: Currently I'm using a shell based command line setup utility, which fullfilles most my my needs. If there are any interests for this let me know. Regards Ralf
Re: auto-import failure for new libXt
On Saturday 20 March 2004 23:32, Brian Ford wrote: I guess this is just a heads up since I don't have time to debug it right now, but with the latest XFree packages, I get a stream of error messages like the following when linking our apps: /home/ford/v9winsym/util/Failure_report/../../../vissym/util/Failure_report /failure_report.c:104: variable '_XtStrings' can't be auto-imported. Please read the documentation for ld's --enable-auto-import for details. failure_report.o(.text+0x203f): In function `main': This used to work, all be it with similar warnings. Is it time to make a pass through the X headers, adding the proper export tags? Ugh... No, only make sure, that you are using -fdata-sections when compiling source and -Wl,--enable-runtime-pseudo-reloc when linking. BTW: You can find detailed informations about this topic in the ld info page (see Machine Dependent/Win32 section) Ralf
Re: KDE3.1 fails to run from a clean install.
On Thursday 25 March 2004 16:39, Crescioli, Phil wrote: Ooops, I forgot to insert my KDE_Log File. Here it is. Last night I did a FULL and COMPLETE download of cygwin from http://kde-cygwin.sourcefroge.net This morning I installed ALL of cygwin and tried to bring up KDE3.1 using startx -multiwindow . KDE came up and allowed me to tweak the desktop environment, then failed to load a library, etc. The log file is below. When I run KDE, I have about 100MB free RAM of the 256 totall memory in my PC. When the first library fails to load, I have about 60MB free RAM. Is my prob not enough free memory, or do I need to tweak a file somewhere To get KDE up and running? FYI-I only set KDE desktop environment to load half the eye candy stuff during the initial setup so as not to have a memory issue. snip + touch /cygdrive/c/Documents and Settings/pcrescioli/.kde_mountchecked touch: creating `/cygdrive/c/Documents': Permission denied There are spaces in your home directory. kde 3.1.4 does not like this. try HOME=/opt/kde3/home startx -multiwindow
Re: .rdata section in Cygwin executables?
On Friday 12 March 2004 15:51, Egor Duda wrote: Joe Buehler wrote: The emacs recompile fails because there is a section in the initially built emacs.exe named .rdata that the unexec() code for Cygwin is not expecting. The section appears to have something to do with exception handling and is only 1k in size. .rdata is a section where read-only data, such as constants, is stored. Most modern OSes and toolchain try to put as much info as possible to read-only segments of binary image because it reduce memory required by programs to run (when program is fork()ed, for instance, read-only pages may be shared between processes) In case of using gcc 3.3x and using auto-imported vars, you should use the '-fdata-sections' flags for compiling sources because otherwise these variables are not detected as variables. See http://sources.redhat.com/ml/binutils/2003-10/msg00256.html for more infos. Just a note. Ralf
compiling error with recent xfree server sources
Hi, I've tried to compile recent xfree server sources from freedesktop cvs area branch CYGWIN (after switching over from the old cvs area by patching all CVS Repository rsp. Root files followed by a cvs update -C -r CYGWIN) and got the following compile error: wincreatewnd.c: In function `winAdjustForAutoHide': wincreatewnd.c:559: error: `ABS_AUTOHIDE' undeclared (first use in this function) wincreatewnd.c:559: error: (Each undeclared identifier is reported only once wincreatewnd.c:559: error: for each function it appears in.) Just an info. BTW: Thanks for the new clipboard stuff, It works very good for kde/cygwin. Great work. Ralf
[PATCH] ioctl FIONREAD implementation for sockets
Hi, while porting a kde game (Kbattleship) to cygwin/xfree I recognized that the ioctl FIONREAD function call wasn't implemented. The appended minor patch added this support to fhandler_socket.cc Cheers Ralf Changelog 2004-02-08 Ralf Habacker [EMAIL PROTECTED] * fhandler_socket.cc (fhandler_socket::ioctl): Added FIONREAD function call. --- fhandler_socket.cc.orig 2003-12-07 23:38:00.0 +0100 +++ fhandler_socket.cc 2004-02-08 15:38:54.508512000 +0100 @@ -1264,6 +1264,13 @@ fhandler_socket::ioctl (unsigned int cmd set_nonblocking (*(int *) p); } break; + + case FIONREAD: + res = ioctlsocket (get_socket (), FIONREAD, (unsigned long *) p); + if (res == SOCKET_ERROR) + set_winsock_errno (); + break; + } syscall_printf (%d = ioctl_socket (%x, %x), res, cmd, p); return res; -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
only a note - microsoft was refering to xfree windows port
Hi all, while reading some stuff about the ms services for unix, I stumpled over a list of xservers in their documentation, where the xfree port is also listed. (probably in the time where it belongs to cygnus, but anyway, they have stated). http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/interop/unix/sfu/sysadmn.asp Running an X-Windows application on Microsoft Windows snip On Windows, you have a set of choices for X server. The prominent ones are: Hummingbird's exceed/W WRQ's ReflectionX Tarantella's XVision XFree86 from Cygnus The above X servers can be considered as X-Windows emulators on Windows. Ralf
KDE 3.1.4 cygwin/xfree release available
Hi all, Last week the first KDE 3.1.4 release of the KDE desktop environment for cygwin/xfree was released. Beside the basic packages it contains already some additional package like kde-i18n, kdevelop, kdeedu, quanta and kdenetwork (alpha version). See http://kde-cygwin.sf.net/kde3/ for further informations. Ralf KDE on cygwin http://kde-cygwin.sf.net
problem with cywin = 1.5.6 and procexp
Hi, sine 1.5.6 (also in recent cygwin snapshots 20040123) the sysinternals.com process explorer procexp found at http://www.sysinternals.com/ntw2k/freeware/procexp.shtml is not able to retrieve process informations from cygwin applications. With 1.5.5 and lower releases there were no problems. The procexp message is unable to query process module information) I've read some informations about changing process security. May be this is responsible for this. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Any WebBrowser for Cygwin?
On Wednesday 21 January 2004 08:38, Dr. Volker Zell wrote: Hi Michael == Michael Henke writes: Michael I want to do X-Forwarding with my Windowx-XP-Box and am using Cygwin SSHd. Michael SSH is working very fine so far. All i need is a browser (except textbrowser Michael like lynx!) for www. Michael Is there any Webbrowser like Mozilla, Netscape or Opera available for the Michael cygwin-X-Server? Where to download and how to compile/install? Try o http://www.dillo.org/ It builds OOTB but needs gtk. Konqueror is also available for cygwin/xfree. See http://kde-cygwin.sf.net/kde3 for more informations Ralf
Re: playing ogg files in cygwin
On Friday 16 January 2004 00:39, you wrote: Ralf Habacker [EMAIL PROTECTED] writes: Just a little note. I've tried yesterday ogg123 from the vorbis-tools 1.0rc3 with recent cygwin snapshot. It works without any problems using oss. However, I can't find any recent cygwin snapshot of vorbis-tools 1.0rc3 on the Internet. Where do you download such a creature? I've got the sources from the linuxtag 2003 dvd and compiled it by myself. You can find sources and binary package on http://kde-cygwin.sf.net/snapshots http://kde-cygwin.sf.net/snapshots/libao-0.8.2.tar.bz2 http://kde-cygwin.sf.net/snapshots/libvorbis-1.0_rc3.tar.bz2 http://kde-cygwin.sf.net/snapshots/libogg-1.0_rc3.tar.bz2 http://kde-cygwin.sf.net/snapshots/vorbis-tools-1.0_rc3.tar.bz2 http://kde-cygwin.sf.net/snapshots/libao-0.8.2-src.tar.bz2 http://kde-cygwin.sf.net/snapshots/libvorbis-1.0_rc3-src.tar.bz2 http://kde-cygwin.sf.net/snapshots/libogg-1.0_rc3-src.tar.bz2 http://kde-cygwin.sf.net/snapshots/vorbis-tools-1.0_rc3-src.tar.bz2 See README.cygwin in the source archive for compiöing instructions. Further sources could be found on http://www.xiph.org/ogg/vorbis/download Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Thanks! ogg123.exe works!
On Friday 16 January 2004 20:10, Bob Clark wrote: Ralf, I couldn't help myself. I just had to try compiling the sources that you pointed me to before I got down to some serious exam grading. I have to say, after reading the README.cygwin file that you recommended, I wasn't too hopeful. The file, in its entirety was, README for cygwin = This source package comes from the linuxtag 2003 dvd. Unter cygwin this source package should be compiled and installed with ./configure --prefix=/usr --disable-dependency-tracking make make install This was pretty generic stuff, so I wasn't expecting what happened next: everything compiled and made right out of the box, and ogg123 worked like a charm! Please note that this source package are preconfigured for cygwin. The original source packages from xiph will probably not be compilable out of the box. I have patched the packages in the following manner, which wasn't be able by a simple diff created patch: libogg export PATH=/usr/autotools/devel/bin:$PATH libtoolize --automake -c -f aclocal # fix libtool problem perl -pi -e 's,file_magic \^x86 archive import\|\^x86 DLL,pass_all,g' aclocal.m4 perl -pi -e 's,allow_undefined_flag\, \$1\)\=unsupported,allow_undefined_flag\, \$1\)\=no,g' aclocal.m4 perl -pi -e 's,shared_ext,shrext,g' aclocal.m4 automake -a -c -f --gnu autoconf libao libtoolize --automake -c -f aclocal # fix libtool problem perl -pi -e 's,file_magic \^x86 archive import\|\^x86 DLL,pass_all,g' aclocal.m4 perl -pi -e 's,allow_undefined_flag\, \$1\)\=unsupported,allow_undefined_flag\, \$1\)\=no,g' aclocal.m4 perl -pi -e 's,shared_ext,shrext,g' aclocal.m4 perl -pi -e 's,^INCLUDES \=,INCLUDES \= -DSHARED_LIB_EXT=\\.dll\\,g' src/Makefile.am automake -a -c -f --gnu autoconf libvorbis export PATH=/usr/autotools/devel/bin:$PATH libtoolize --automake -c -f aclocal # fix libtool problem perl -pi -e 's,file_magic \^x86 archive import\|\^x86 DLL,pass_all,g' aclocal.m4 perl -pi -e 's,allow_undefined_flag\, \$1\)\=unsupported,allow_undefined_flag\, \$1\)\=no,g' aclocal.m4 perl -pi -e 's,shared_ext,shrext,g' aclocal.m4 perl -pi -e 's,libvorbisfile_la_LDFLAGS = ,libvorbisfile_la_LDFLAGS = libvorbis.la ,g' lib/Makefile.am perl -pi -e 's,libvorbisenc_la_LDFLAGS = ,libvorbisenc_la_LDFLAGS = libvorbis.la ,g' lib/Makefile.am automake -a -c -f --gnu autoconf vorbis-tools export PATH=/usr/autotools/devel/bin:$PATH libtoolize --automake -c -f aclocal # fix libtool problem perl -pi -e 's,file_magic \^x86 archive import\|\^x86 DLL,pass_all,g' aclocal.m4 perl -pi -e 's,allow_undefined_flag\, \$1\)\=unsupported,allow_undefined_flag\, \$1\)\=no,g' aclocal.m4 perl -pi -e 's,shared_ext,shrext,g' aclocal.m4 perl -pi -e 's,win32/Makefile,,g' configure.in perl -pi -e 's, [EMAIL PROTECTED], [EMAIL PROTECTED]@ [EMAIL PROTECTED],g' oggenc/Makefile.am perl -pi -e 's,LIBICONV\@ [EMAIL PROTECTED],SHARE_LIBS\@ [EMAIL PROTECTED],g' vorbiscomment/Makefile.am automake -a -c -f --gnu autoconf I still have other hurdles to overcome before I'm satisfied (such as getting gmpeg to integrate successfully with the ogg stuff), but getting ogg123 to work had been driving me crazy for the past several days! Thanks again for your most generous attention! That was my first post to the cygwin mailing list. I wish that I had done it much sooner. I'm going to repaste those websites that you pointed me to for the mailing list archives in the hope that it will save some other souls all the trouble that I've had with this issue. I would have never thought to look in the kde repository for ogg vorbis stuff. This is because the recent kde-3.1.4 cygwin release provides ogg support in konqueror. Under linux arts provides ogg support, but for several reasons we are not using arts (the main reason is it is to slow and too big), so we were looking for a smaller solution and found it in using small external sound player, vorbis ogg for ogg, madplay for mp3 and a self written wave player for wave formats. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: playing ogg files in cygwin
On Tuesday 13 January 2004 23:58, Ralf Habacker wrote: On Tuesday 13 January 2004 19:51, Bob Clark wrote: Sven Köhler [EMAIL PROTECTED] writes: i also think, that cygwin doesn't have any OSS emulation, does it? it have using /dev/dsp. For the kde-3.1.4 cygwin port I've tried to build ogg123 and it does have problems with playing sounds using /dev/dsp. ogg123 uses threads for buffering and playing sounds and it seems to me that there are the problems. I had not enough time to find the problem, so I stopped this port yet. Just a little note. I've tried yesterday ogg123 from the vorbis-tools 1.0rc3 with recent cygwin snapshot. It works without any problems using oss. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot load libphp4.dll into server: dlopen: Win32 error 998
On Wednesday 14 January 2004 18:19, tosch wrote: Hi, while trying to install a PHP-Wiki on cygwin i got several (i think quit all) problems with mod_php which were described in the thread More Apache/PHP installation puzzles. I finally reached this point: # /usr/sbin/apachectl start Syntax error on line 236 of /etc/apache/httpd.conf: Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error 998 /usr/sbin/apachectl start: httpd could not be started libphp4.dll was set (setfacl) to exactly the same permissions as f.i. mod_cgi.dll i did NO rebase as suggested by Igor Meanwhile there is probably newer knowledge. My Latin is at it's end. You may download and install the dependency walker http://www.dependencywalker.com/ and open it from a bash shell with depends `cygpath -aw /usr/sbin/httpd.exe` Then try to profile this application with F7. Please activate at least the following options: - Log Dllmain calls for process attach ... - Hook the process ... - Use full path when logging - Automatic open profile child processes. and start the profiler. In the lower box you will see the log messages. If there are any problems, then it will be printed in red or bold. hope that helps Cheers Ralf Could anybody help please. Thanks in advance, tos __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot load libphp4.dll into server: dlopen: Win32 error 998
On Wednesday 14 January 2004 18:19, tosch wrote: Cannot load /usr/lib/apache/libphp4.dll into server: dlopen: Win32 error 998 BTW: This error means that some dll's could not be accessed, my be because the executable bit isn't set. The dependency walker will show you, which dll is affected. grep 998 /usr/include/w32api/winerror.h #define ERROR_NOACCESS 998L Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/X Representation at LinuxWorld Expo in New York City - Jan 21 to Jan 23
On Wednesday 14 January 2004 05:20, Harold L Hunt II wrote: In an exciting, and very recent, turn of events, I will be attending LinuxWorld Expo in New York City from Wednesday January 21st 3:00 PM to Friday January 23rd 4:00 PM. This trip has been made possible by funding from X.org, for which I am extremely grateful. Nice to hear. Ralf
Re: playing ogg files in cygwin
On Tuesday 13 January 2004 19:51, Bob Clark wrote: Sven Köhler [EMAIL PROTECTED] writes: i also think, that cygwin doesn't have any OSS emulation, does it? it have using /dev/dsp. For the kde-3.1.4 cygwin port I've tried to build ogg123 and it does have problems with playing sounds using /dev/dsp. ogg123 uses threads for buffering and playing sounds and it seems to me that there are the problems. I had not enough time to find the problem, so I stopped this port yet. /dev/dsp has directly wave support, although the device handler does play the wave header, which result ins some start noice on playing. (This seems a known issue, because i've found a note in fhandler_dsp.cc about this problem) Additional we have compiled arts the unix related kde sound system using /dev/dsp successfully, altough there are latency problems caused by the fixed 16KB buffer size, which couldn't be changed by an application. A buffer size of 1KB would be better for our cases, but this value would be also fixed. I have prepared a patch for changing the buffer size, but hadn't found time to check this very deeply, so it may be need some more time for contributing, but if someone is interested to get this let me know. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: QT 3.2.3 cygwin/XFree release available
On Monday 12 January 2004 11:08, Dr. Volker Zell wrote: Ralf == Ralf Habacker writes: Ralf today the cygwin/XFree port of the QT 3.2.3 X11 release based on the recent Ralf cygwin release is ready containing binary and source package. The following configure test for QT fails: conftest.cc: What is the right link command to link with qt-3.2.3 release ? BTW the release is missing the qmake.conf file for the cygwin platform That is the reason why the link line fails. Which release are you using qt-3.2.3-1 or qt-3.2.3-2 ? qt-3.2.3-1 misses an important file (.qmake.cache) and the -2 release does not have the /etc/profile.d script. I'm currently preparing an updated release. See http://kde-cygwin.sf.net/qt3/compiling.php for further informations. BTW: Compiling files requires -fdata-sections and link lines should require -Wl,--enable-runtime-pseudo-reloc Ralf
Re: window decoration for multiwindow mode
On Sunday 04 January 2004 01:10, Kensuke Matsuzaki wrote: Hi, A new window manager XWinWM handles Motif WM Hint and Blackbox hint, and kicker has no border. XWinWM is based on Hackedbox, and Hackedbox doesn't use _NET_WM_WINDOW_TYPE atom. I have to supprot EWMH, but XWinWM has preblem on more basically window management (Move, resize, iconify etc). So now EWMH compliance's priority is not high for me. Test version is here. http://peppermint.jp/products/x/xwinwm-0.0.1.tar.gz Thanks for this info. Can't say, when I can take a look at this, but I will see probably after the kde 3.1.4 release.
some questions relating kde-cygwin and XWin
Hi, 1. for the next kde-cygwin 3.1.4 release I'm going to build a start script, which starts all required applications like ipc-daemon2, XWin and KDE basic apps and kills this processes after a logout, if they are started by the script. I like to build this script without any inferences especially to other XWin instances running on other displays, so I'm required to get the pid of the started XWin instance. I've search in the sources of the Xserver but, have not found any useable feature, so my question is, is there any way known to retrieve the pid of a started XWin instance or is there a possibility to shutdown the server by a xclient app ? If there is no such feature, what about adding a command line option to store the server pid in a file ? 2. The Xserver could be shutdowned by the Tray X icon or by the X in the Xwin windows title. I've read that Xwin now supports specific menu entry (I remember only that this was implemented, not more) I'm looking for a way to run a script for an controlled kde shutdown after triggering a server shutdown but before the xserver shutdown is performed. Unfortunally I haven't found and doc about this in the xfree docs neither I found any usefull thread with an overview of this feature for evaluating a possible implementation, so my question is if anone can give me a pointer to some docs. 3. run.exe does not support space in path. I've search for any sources, but haven't found anyone only the binary seems to available in startup-scripts package. So my question is, if this could be fixed ? BTW: There is a font size problem on http://xfree86.cygwin.com/devel/server in the Topic Souce Code: Ralf
window decoration for multiwindow mode
Hi, i just saw the xfree development page and recognized a missing feature in the multi window mode, which is is at least interesting for kde, but I assume also for other x applications. Currently the server does not handle modal dialogs like expected (currently modal dialogs are independed windows) and does not support windows without regular windows title border. (This could be verifyed for example with kicker, the KDE panel, which is bordered with a regular window title, while it is shown without any additional border as expected using an X-window manager like kwin. The relating standards for this topic could be found at http://www.freedesktop.org/standards/wm-spec/1.3/ar01s05.html _NET_WM_WINDOW_TYPE, ATOM[]/32 This SHOULD be set by the Client before mapping to a list of atoms indicating the functional type of the window. This property SHOULD be used by the window manager in determining the decoration, stacking position and other behavior of the window. The Client SHOULD specify window types in order of preference (the first being most preferable) but MUST include at least one of the basic window type atoms from the list below. This is to allow for extension of the list of types whilst providing default behavior for Window Managers that do not recognize the extensions. Rationale: This hint is intended to replace the MOTIF hints. One of the objections to the MOTIF hints is that they are a purely visual description of the window decoration. By describing the function of the window, the Window Manager can apply consistent decoration and behavior to windows of the same type. Possible examples of behavior include keeping dock/panels on top or allowing pinnable menus / toolbars to only be hidden when another window has focus (NextStep style). _NET_WM_WINDOW_TYPE_DESKTOP, ATOM _NET_WM_WINDOW_TYPE_DOCK, ATOM _NET_WM_WINDOW_TYPE_TOOLBAR, ATOM _NET_WM_WINDOW_TYPE_MENU, ATOM _NET_WM_WINDOW_TYPE_UTILITY, ATOM _NET_WM_WINDOW_TYPE_SPLASH, ATOM _NET_WM_WINDOW_TYPE_DIALOG, ATOM _NET_WM_WINDOW_TYPE_NORMAL, ATOM _NET_WM_WINDOW_TYPE_DESKTOP indicates a desktop feature. This can include a single window containing desktop icons with the same dimensions as the screen, allowing the desktop environment to have full control of the desktop, without the need for proxying root window clicks. _NET_WM_WINDOW_TYPE_DOCK indicates a dock or panel feature. Typically a Window Manager would keep such windows on top of all other windows. _NET_WM_WINDOW_TYPE_TOOLBAR and _NET_WM_WINDOW_TYPE_MENU indicate toolbar and pinnable menu windows, respectively (i.e. toolbars and menus torn off from the main application). Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. It is distinct from type TOOLBAR because it does not correspond to a toolbar torn off from the main application. It's distinct from type DIALOG because it isn't a transient dialog, the user will probably keep it open while they're working. Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window. _NET_WM_WINDOW_TYPE_SPLASH indicates that the window is a splash screen displayed as an application is starting up. _NET_WM_WINDOW_TYPE_DIALOG indicates that this is a dialog window. If _NET_WM_WINDOW_TYPE is not set, then windows with WM_TRANSIENT_FOR set MUST be taken as this type. _NET_WM_WINDOW_TYPE_NORMAL indicates that this is a normal, top-level window. Windows with neither _NET_WM_WINDOW_TYPE nor WM_TRANSIENT_FOR set MUST be taken as this type.
Re: New webpage: Cygwin/X Features
On Wednesday 24 December 2003 08:34, Harold L Hunt II wrote: I have added a Cygwin/X Features webpage due to request by users and to ease the job of getting Cygwin/X accepted by business users: http://xfree86.cygwin.com/features.html The list of features currently has about 17 items on it. We really have some neat features! :) I know that I have forgotton some mentionable features, but it is time for bed. Please send in suggestions for additional items to the mailing list; just mention the feature and I can write the description for the actual webpage. Harold Nice page - I've found a spelling error in: DirectDraw Acceleration - .. Mutli-Window ... Ralf
Re: How to set breakpoints before mainCRTStartup?
On Tuesday 23 December 2003 18:23, Dalibor Topic wrote: in my attempts to fix an ugly bug in kaffe on Cygwin, the bug I'm trying to squish turned out to be triggered by something that happens *before* main is called. you can set a breakpoint at the application entry point. $ gdb /bin/bash snip (gdb) info file Symbols from /usr/bin/bash.exe. Local exec file: `/usr/bin/bash.exe', file type pei-i386. Entry point: 0x401000 0x00401000 - 0x0047b754 is .text 0x0047c000 - 0x00480d90 is .data 0x00481000 - 0x00488f60 is .bss 0x00489000 - 0x0048a12c is .idata (gdb) b *0x401000 Breakpoint 1 at 0x401000 (gdb) r Starting program: /usr/bin/bash.exe Breakpoint 1, 0x00401000 in ?? () (gdb) Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
AW: HEADSUP: cygserver now has MSG, SEM and SHM support
Corinna Vinschen wrote: Ok, I don't know how that's implemented in cygipc so I think it might be necessary to mention that: The implementation of the MSG, SEM and SHM functions in Cygwin are so that if the functions are not available (be it that CYGWIN doesn't contain the word server or Cygserver isn't running) not only set errno to ENOSYS, but they also raise a SIGSYS. So it's crucial that your code handles that signal. At least, it should ignore it (signal(SISYS, SIG_IGN)). Harold for the Xserver that means, that the shm initialisation code has to be changed to the detecting code used by FreeBSD and friends (CheckForShmSyscall() in Xserver/Xext/shm.c and Xserver/Xext/xf86bigfont.c) The cygipc-related stuff could then be removed in both files. Ralf
AW: AW: [PATCH] setup - help and local dir commandlineoptionswasRe: Setup Command Line Options
Rob, 2. There are several ways to build the api of such a engine, smaller approachs (using mostly available code and classes) or bigger approach (complete rewrite), so at first I would prefer to use the current code base and to apply minimal changes (see below) to enable gui and command line applications. The above suggested design could then be implemented step by step (which means that the current windows message stuff will be used) I think you'll find that that is a hard approach to take, as commandline apps don't have an event loop unless you get into creating a hidden window and so forth. The minimal engine API I proposed is a reuse strategy, but various code will have to be converted as you go. agreed, I assumed that the event loop has to be in the gui stuff, 3. While some classes of the recent code base are gui independent, there are others which contains gui and non gui stuff intermixed, which should be cleaned up/separated before or while moving to a implementing. Yes. Needed changes: 1. defining a rule for class/file naming scheme. There some packages which http://www.cygwin.com/ml/cygwin-apps/2003-03/msg00750.html or GUIDELINES in the source code. Thanks 2. remove intermixing of GUI and non gui classes in one file Yes - I addressed this in my roadmap. AntiVirus.cc for example contains a class AntiVirusPage, which provides the gui stuff and AntiVirus for the non gui stuff. If the functionality of this classes would be separated in such a manner, that the gui class(es)s contain only gui related stuff, the gui related stuff could be commented out by a C define. Unfortunally this isn't true in the most cases I found. Using this files in a command line tool need reorganisation of such files, which could be done in three flawors: 2.1. reassign the classes functionality and comment out gui stuff with #ifdef USE_GUI ... #endif and not defining USE_GUI for command line apps or 2.2. move the gui stuff in a new file named like the containing major class for example AntiVirusPage.cc for the AntiVirusPage class. 2.3. leave the gui file naming like it is and create a new similar named file for the engine containing the non gui stuff in a different dir (like I have done in the proof of design) A different dir isn't needed for now. 2.1 isn't acceptable, as I don't want to have to compile classes twice. agreed 2.2/2.3 are essentially the same and as long as a different dir isn't prematurely used are both fine. see below Yes. I sketched out a fairly minimal development path to generate a commandline setup that doesn't involve forking the engine code. You haven't commented on the approach, rather you appear to have just ignored it completely. Why ? What is wrong with separating files into different dirs in a proof of design to get a better overview of the dependencies. May be you are very familiar with this code so you don't need something like this, but it helped me very much to get a clearer image about the dependencies. This is no forking. Also see 2. for the need of some separation. CVS doesn't have the facilities for tracking movement of source files properly. 1. This may a reason for not separating, but there are several solutions a. you can add a move hint like class AntiVirusPage moved to/from AntiVirusPage.cc in the related files log message a. we are already forced yet to move classes to other files like the class AntiVirusPage and other. Until the engine is separate, and complete, we won't know for sure what is in the engine, and whats in the UI. For instance, will we use res.rc in the commandline, or switch to gettext? (I suspect res.rc in the commandline). Does that mean we need to split res.rc? or do we just ignore the overhead. The only usable parts from res.rc are the stringtables, but this isn't very much, so this duplicating may not be a major problem. Regardless of the used way I think we should define a generic function to retrieve language strings, so that we can implement whatever we want. Additional there is the question, should the engine code reports clear text messages or only return values, so that the message text in only located in the frontends. Providing engine related error messages in the engine may reduce duplication. What about let returning the engine error codes and providing an additional engine function to retrieve the error messages ? gettext versus res.rc - I have to think a little more about this. 2. In general this are reason to separate very early because it enforces the developer to think about the context where the code belongs. At first this requires a little more efforts to get thins running, but I think this is worth while. (This is exactly the reason why I have moved the files a different dir in the provided sources, I have already moved about 80% of the code) So do what you like to say ? Should we separate now or not ?
AW: [Patch] Resizing fixes
Hi On Fri, 2003-10-31 at 23:33, Frank Richter wrote: This patch now properly deals with minimizing the window - before, some sizes/positions were slightly off when the window was minimized and restored. It also constraints the size of the property sheet, it now can't get smaller than it's initial size. APplied. Please submit patches with diff -up always - they are much easier to read, and more robust at applying to altered source. I've tried the resizing stuff and it is really great. While i'm working with this, I've got two ideas for improving the general selection window. The first one is to split the list into two parts: a category window on the left side and a package list on the right (like yast on suse linux) and second a search field to search for a specific package. I see some advantage of this: 1. The navigation through packages would be a easier because the items on the category list are scollable independantly from the package list. 2. the package windows does not need a horizontal scrollbar, because the package informations are printed on the window bottom when selecting a package, this reduces the needing scrolling operations to read the package info. In short: The user does see more information at one time. 3. The search field allows a very fast access to each individual package. category packages release +--++-+ |+All(2) || x [cygwin-doc]1.2-4 | |+Admin|| - docbook-xml42| |+Archive || - docbook-xsl | |+Base || (1) | |+Database || | |+Devel|| | |[Doc] || | |+Editors || | |+Games|| | | || | | ... || | +--+| | search packages | | +--+| | | || | +--++-+ package info +-+ |cygwin specific information, including man pages and | |User's guide | +-+ (1) this icon could be toggled through install (with choosing the requested releases), uninstall, reinstall, upgrade,... (2) I don't think that it makes sense to add a install, uninstall button for each category. Makes it sense to install *all* databases or *all* editors ? I don't think so. Upgrading all packages in this category makes more sense, i think. Only a little note. BTW: Currently I'm very busy with the command line version of setup, afterthat I probably will be able to contribute to this. Ralf
AW: AW: [PATCH] setup - help and local dir command lineoptionswasRe: Setup Command Line Options
On Sat, 2003-11-01 at 12:16, Ralf Habacker wrote: Rob I need more time to think about what you have written and how to start with which class, I have take some time to inspect how it could be go and have build a testcase to see what kind of api is needed. Please note that I am concentrated only to get a command line version initial running, so I've removed the not needed gui stuff. Currently I can't send in a patch for this, because I have splitted the relating engine files into subdir and build a static library to allow file including checks, although the binariy and sources could be downloaded here: binary http://kde-cygwin.sf.net/snapshots/enginetest-0.0.1.exe. source http://kde-cygwin.sf.net/snapshots/setup_new-0.0.1.tar.bz2 Sounds like you've gone too far too fast. I don't have the time to review a non-delta set of changes. Particularly ones that throw away a lot of code (the gui) that -must- be retained. I think there are some mißunderstandings. This code is *not* ready for reviewing. This is a step before, because while I'm working on this I have found some specification needs of the basic design. Let me explain what I mean: 1. Definition of the term engine. Actually I understand under the engine all classes, functions and structures of the recently setup installer, which could be used are a common base to build gui or command line based installer. This definition may differs from your view, sow we have to adjust this. I don't have a particular preference, but I've listed those in likely order of difficulty (for migration from the current code base) - and we should only use one approach. If we want to use windows messages, I suspect we want to wrap the engine in an adapter - as the command line tool won't have a message loop. * never throws exceptions: all errors must be handled in the engine, and propogated to the UI via the callback mechanism. (We need a callback for engine termination.) The UI needs to be able to: * query the engine for the available options * hand user details into the engine * retrieve structured data (ie. the list of sites) * attempt to action a given stage of the engine. * display progress of long running tasks. 2. There are several ways to build the api of such a engine, smaller approachs (using mostly available code and classes) or bigger approach (complete rewrite), so at first I would prefer to use the current code base and to apply minimal changes (see below) to enable gui and command line applications. The above suggested design could then be implemented step by step (which means that the current windows message stuff will be used) 3. While some classes of the recent code base are gui independent, there are others which contains gui and non gui stuff intermixed, which should be cleaned up/separated before or while moving to a implementing. Needed changes: 1. defining a rule for class/file naming scheme. There some packages which are written lowercase (1) and some mixed (2). What's the prefered one ? some examples (this is mainly for me to learn what the current strategy is) typeclass file 1 packagemeta package_meta(.h|.cc) 1 packagedb package_db(.h|.cc) 2 UserSetting UserSetting(.h|.cc) 2 AntiVirus AntiVirus(.h|.cc) (see topic 2) AntiVirusPage AntiVirus(.h|.cc)(see topic 2) 2. remove intermixing of GUI and non gui classes in one file AntiVirus.cc for example contains a class AntiVirusPage, which provides the gui stuff and AntiVirus for the non gui stuff. If the functionality of this classes would be separated in such a manner, that the gui class(es)s contain only gui related stuff, the gui related stuff could be commented out by a C define. Unfortunally this isn't true in the most cases I found. Using this files in a command line tool need reorganisation of such files, which could be done in three flawors: 2.1. reassign the classes functionality and comment out gui stuff with #ifdef USE_GUI ... #endif and not defining USE_GUI for command line apps or 2.2. move the gui stuff in a new file named like the containing major class for example AntiVirusPage.cc for the AntiVirusPage class. 2.3. leave the gui file naming like it is and create a new similar named file for the engine containing the non gui stuff in a different dir (like I have done in the proof of design) Here a general decision of the maintainer is required. There may be more issues, but I think for now is is enough and I'm waiting for your comments. Yes. I sketched out a fairly minimal development path to generate a commandline setup that doesn't involve forking the engine code. You haven't commented on the approach, rather you appear to have just ignored it completely. Why ? What is wrong with separating files into different dirs
AW: Performance measurement data: find
hi, procexp: display same fields as task manager and -see DLL's used and where loaded in memory for each program running - See all open handles and what they point to - See each thread, it's cpu time and what module it is executing in and it's call stack - see all cpu time accounted for (numbers add to 100% within small tolerance due to disparity of time of getting info during update - uses no cpu when minimized -can save process summary list and fields to file alot more contig: make any/all files contiguous (can be run as background batch job every few hours on entire disk to keep disk defragmented) pagedfg: defragment system files on boot regmon: monitor registry accesses (with filtering) filemon: does the same for file accesses tcpview: shows all tcp connections listening or connected - optional force handle closed tdimon: monitor transport layer system calls dbgview: view system debug calls pstools: command line ps utils inspired from unix utils autoruns: Show auto-start programs including new ones that msconfig doesn't show winobj: display windoes OS-internal object space. --- They are all from the author of the book Inside Windows 2000. He really knows his stuff and his tools should be part of every engineers toolbox. Nice overview. I have found some more nice tools like dependency walker or windows strace or windows kernel debugger listed with direct links on http://kde-cygwin.sourceforge.net/links/other.php#Debugging Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
AW: AW: [PATCH] setup - help and local dir command line optionswasRe: Setup Command Line Options
Rob
On Sat, 2003-10-25 at 22:23, Ralf Habacker wrote:
This is in the wrong place: LocalDirSetting::load is the
right method to
query the option from.
While thinking about this a while more, I recognized that there
is some more
basic work necessary how to design the command line interface.
Are there any other requests or hints about the design ?
I've roughed stuff out here before, I think. Anywhere, here goes a quick
brain dump.
I need more time to think about what you have written and how to
start with which class,
I have take some time to inspect how it could be go and have build a
testcase to see what kind of api is needed. Please note that I am
concentrated only to get a command line version initial running, so I've
removed the not needed gui stuff. Currently I can't send in a patch for
this, because I have splitted the relating engine files into subdir and
build a static library to allow file including checks, although the binariy
and sources could be downloaded here:
binary http://kde-cygwin.sf.net/snapshots/enginetest-0.0.1.exe.
source http://kde-cygwin.sf.net/snapshots/setup_new-0.0.1.tar.bz2
I have done the following steps to get a compiled exe.
cd .../setup_new
mkdir debug
cd debug
../configure CXX=g++ -mno-cygwin CC=gcc -mno-cywin
cd engine
make
This will build the library and the enginetest applications, which has some
basic functionality like:
enginetest-0.0.1.exe --query --all - list all installed packages
enginetest-0.0.1.exe --query --list packagename - list all files of the
installed package
The main problem after finding where to remove/hack the gui related stuff,
is to detect the needed objects/method for the requested operation. Is is
sometimevery hard to follow the current code base and some light for this
would be nice, so it there is someone how can give me some more informations
(ideal would be some basic coding like mentioned below) it would be nice.
For the currently implemented (and some more I'm going to implement)
functions the used objects/methods are listed below
snip
if (QueryPackageOption) {
if (ListAllPackagesOption) {
packagedb db;
db.listAllPackages(cout); [new method of packagedb]
}
if (ListFilesInPackagesOption) {
packageversion pkg = cygpackage::createInstance(argv[optind]);
String s = pkg.getfirstfile();
while (s.size() 0) {
cout s.cstr() endl;
s = pkg.getnextfile();
}
}
}
/*
site list handling
- list all mirrors
- allow user to choose one mirror
related functions/classes/methods
// clear selected mirror
site_list.clear ();
get_site_list(http://sources.redhat.com/cygwin/mirrors.lst;); [uses
parameter instead of using LoadString()]
// iterate throug the site lists.
for (SiteList::const_iterator n = site_list.begin (); n !=
site_list.end
(); ++n)
// set used mirror
site_list = all_site_list[mirror];
*/
/*
install/reinstall/upgrade/remove packages
static BoolOption DownloadOption (false, 'D', download, Download
from
internet);
static BoolOption LocalOption (false, 'L', local-install, Install
from
local directory);
static BoolOption InstallOption (false, 'I', install, Install from
internet);
or
static StringOption SourceURLOption (false, 'S', source-packages,
source package path (http,ftp,file,rsync,...));
static BoolOption InstallOption (false, 'i', install, Install);
static BoolOption InstallOption (false, 'e', erase, erase package);
static BoolOption InstallOption (false, 'u', upgrade, upgrade
package);
static BoolOption InstallOption (false, 'f', fresh, reinstall
package);
if (DownloadOption)
source = IDC_SOURCE_DOWNLOAD;
else if (LocalOption)
source = IDC_SOURCE_CWD;
else
source = IDC_SOURCE_NETINST;
Taskhandling
packagedb db;
db.task = source == IDC_SOURCE_DOWNLOAD ? PackageDB_Download :
PackageDB_Install;
How it goes on
*/
Any comments ?
Cheers
Ralf
RE: [PATCH] setup - help and local dir command lineoptionswasRe: Setup Command Line Options
On Mon, 2003-10-27 at 03:49, Ralf Habacker wrote: Hi Rob, Oh, and please resubmit the patch with the correction I requested.. Rob here is it. I hope it is correct now. Not quite: I'm not in the business of splitting up patches and adjusting changelogs - could you please provide: The patch for main.cc and localdir.cc The updated changelog Here is it. Ralf Changelog 2003-10-27 Ralf Habacker [EMAIL PROTECTED] * main.cc (HelpOption): New instance. (main): Added help command line option handling. * localdir.cc (LocalDirOption): New instance. (LocalDirSetting::load) allow setting localdir from command line. help_and_local_dir_cmd_options.patch Description: Binary data
AW: Problems with shared lesstif and shared Xt on Cygwin/XFree86
Hi Harold L Hunt II wrote: I tried a build without $(SMLIB) and $(ICELIB) in SharedXtReqs, but it fails to link due to unresolved symbols (all symbols must be resolved at library link time in DLLs on Windows). I will have to consult with the rest of the Cygwin people to see what we should do now. I'm working on a similar problem with libXfont. The more I think about it, the more problems I see and I think this is a feature, which ld must provide. The cases where the symbol is undefined in the shared library might get resolved with dispatch functions and code in the program which changes the pointer which is used by the dispatch code. This might be possible, but how could ld find the propper library ? Let me explain a few notes to this topic, may be this helps to understand the relating things a little bit more. linux and other unix os uses a runtime search for such symbols through ld.so, ldconfig and friends. (see http://www.cs.princeton.edu/cgi-bin/man2html?ld.so.1:1 and http://www.cs.princeton.edu/cgi-bin/man2html?ld.so.1:1 for more informations) Beside the recommended linker patch, something like the above mentioned ld.so functionality has to be implemented too. There must be a runtime specific code located somewhere in the (mingw- and cygwin's) applications startup library (like the pseudo-runtime-reloc code see http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00205.html) or somewhere else. As far as I can see the runtime stuff could be implemented in two manners: 1. when the dll is loaded by the dll startup code. The loading stuff searches the PATH (or using an newly introduced LD_LIBRARY_PATH) environment var for dll's and their exported symbols to find a valid symbol and resolves this reference. 2. at the time an unresolved symbol is called (lazy binding, ms and other native win32 linkers are supporting such a mode). Unfortunally this work only with functions symbols and not with data symbols, because of the different accessing mode (call versus content loading/writing). Both cases increases the loading time of an application and may end up in seg faults in case more than one dll exports the requested symbol and the search path is searched in an unwanted order. The increased loading time could be reduced by a dependency cache like ldconfig does, but this decision could be reached in real test scenarios. For the dll ordering problem currently I have no idea how to fix, may be someone else can help with this. The linker patch should contain the following parts: 1. a command line options to enable/disable dynamic-runtime-linking support ( --[no-]allow-shlib-undefined seems to be usable) 2. it has to detect unresolved symbols and shuld build internal code stubs (like the regular function import stub) to solve symbol requests. For the runtime stuff is has to provide internal tables (the dynamic import table) allowing the runtime stuff to find and resolve this dependencies. These import tables are probably not be visible in the PE-dll supplied import, they are only internal defined. Another approach seems to be to link all such undefined symbols to one known symbol in an specific helper dll, augmented with the original symbol in an currently unspecified decoration, so that this dll is able to solve the undefined symbol. The advantage of this solution is that there is no specific runtime stuff in each dll or application necessary. All this stuff is located in one dll and could be upgraded and improved independently from the real application or dll's (for cygwin this dll will be probably cygwin1.dll, for mingw the mingwxx.dll). BTW: I've cc'ed this email to the binutils list, because there are more people with ld knowledge, who can give some more informations/solutions for this issue. Hope that help Ralf (It may be possible to us a dummy dll'
AW: AW: [PATCH] setup - help and local dir command line optionswasRe: Setup Command Line Options
Rob, On Sat, 2003-10-25 at 22:23, Ralf Habacker wrote: This is in the wrong place: LocalDirSetting::load is the right method to query the option from. While thinking about this a while more, I recognized that there is some more basic work necessary how to design the command line interface. Are there any other requests or hints about the design ? I've roughed stuff out here before, I think. Anywhere, here goes a quick brain dump. I need more time to think about what you have written and how to start with which class, but let me ask one question now, perhaps you can fix this: Have you tried to compile the inilint example in the last time ? I have to add so many additional files because of dependencies and the last one 'threebar.o' one introduce a gui class, so the example could not be build as console application :-( These one I have to add package_version.$(OBJEXT) package_db.$(OBJEXT) \ cygpackage.$(OBJEXT) package_meta.$(OBJEXT) package_source.$(OBJEXT) \ compress.$(OBJEXT) compress_gz.$(OBJEXT) compress_bz.$(OBJEXT) hash.$(OBJEXT) log.$(OBJEXT) \ mklink2.$(OBJEXT) mount.$(OBJEXT) msg.$(OBJEXT) state.$(OBJEXT) dialog.$(OBJEXT) script.$(OBJEXT) download.$(OBJEXT) threebar.$(OBJEXT)\ ... Ralf
AW: AW: cygwin.rules - Enabling shared libXt finally?
No, there is no functional changes. I only want to make sure, that no c function in Intrinsic.c can use the symbol _y (in c 'y'), so this patch renames it to __$XtInherit, which isn't usable for c functions. BTW: I was very in rush while doing the last patch, which may fails to be applied. The symbol which has to be patched is _y and not _$$y like done in the previous patch. I've added an updated patch. Ralf --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_y \n\ - _y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit Ralf Errm, this isn't going to change the public interface is it? That is, if Harold releases another libXt with this change, would that break the recently re-compiled and released lesstif, etc etc? -- Chuck Ralf Habacker wrote: Not sure I understand. What should be changed in the current version of the Xt code? only note 1, chaning the label. The second note is only for completeness. Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. Please send a diff against these if anything should be changed. Note that these are intentionally from the 4.3 branch. --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_$$y \n\ - _$$y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit
Re: cygwin.rules - Enabling shared libXt finally?
Harold, It looks like you got it nailed to me. I am testing a build right now. I have too additional notes to this patch. 1. Because _Xtinherit is exported as a data symbol, immediate calls to this function in the manner ... _XtInherit(); ... will be relocated wrongly and should be avoided ( I have seen this, but does not know currently why this happens). A workaround in case this is absolutly required is to use the following stuff. void (*func)(void); func _blah_blah = XtInherit; ... (*_blah_blah); ... 2. In the patch there is a symbol named _y. This should be renamed to a name, which couldn't be used by regular functions for example _$Xtinherit_ref or so. The '$' isn't a valid c function name. Ralf
AW: cygwin.rules - Enabling shared libXt finally?
Harold Not sure I understand. What should be changed in the current version of the Xt code? only note 1, chaning the label. The second note is only for completeness. Attached are my curent xc/lib/Xt/[Initialize.c|IntrinsicP.h] files. Please send a diff against these if anything should be changed. Note that these are intentionally from the 4.3 branch. --- Initialize-old.c 2003-10-21 20:21:18.0 +0200 +++ Initialize.c 2003-10-21 20:23:25.0 +0200 @@ -236,8 +236,8 @@ asm (.data\n\ .globl __XtInherit\n\ - __XtInherit: jmp *_$$y \n\ - _$$y: .long ___XtInherit \n\ + __XtInherit: jmp *__$XtInherit \n\ + __$XtInherit: .long ___XtInherit \n\ .text \n); #define _XtInherit __XtInherit
AW: Patch for building libcrypt.a as a DLL
On Sun, Oct 19, 2003 at 09:31:44PM +0200, Ralf Habacker wrote: BTW: There is another lib, libutil.a in the inetutils package, which causes same libtool problems Please don't use libutil.a anymore. All functionality intentionally exported from libutil.a is now exported genuinely by the Cygwin DLL itself, beginning with release 1.5.5. These functions are getusershell setusershell endusershell daemon forkpty login_tty logwtmp openpty revoke Additionally, Cygwin exports updwtmp now, too. Libutil.a is deprecated and will not be part of future inetutils releases anymore. Only for cygwin or for the whole unix/linux world ? It seems that some linux based packages (as far as I know kde releated package) are using libutil as default, which requires additional patching. For this it would help, building a special import library containing the libutil relating symbols pointing to the cygwin dll like done with libpthread. Ralf Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Developermailto:[EMAIL PROTECTED] Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
AW: Patch for building libcrypt.a as a DLL
Hi Charles, this is very suprising. I have noted for the next to make a note exactly of this library. The reason for this is, that KDE had upgrades their libtool release to on to the newest cvs release and file_magic dependency style is not the default. Thanks very much for your effort. BTW: There is another lib, libutil.a in the inetutils package, which causes same libtool problems Ralf -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Charles Wilson Gesendet: Samstag, 18. Oktober 2003 23:21 An: [EMAIL PROTECTED] Betreff: Patch for building libcrypt.a as a DLL This should make life a little simpler for those apps that use libtool to build DLLs and depend on libcrypt -- since libtool tries very hard to ensure that all dependencies of a DLL are themselves DLLs. Corinna, please consider this patch. -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
ash does not understand '~'
Hi,
the following shell script does not work at least with ash-20031007-1
although I don't see any reason why this should not be a valid syntax. If
you use
export PATH=${HOME}:/usr/bin
then the scripts runs. bash has no problems with this.
--- ~/test ---
#!/bin/sh
export PATH=~:/usr/bin
test2
--- ~/test2 ---
#!/bin/sh
echo test2
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
AW: ash does not understand '~'
Hi the following shell script does not work at least with ash-20031007-1 although I don't see any reason why this should not be a valid syntax. If you use The reason is, '~' is an extension to the bourne shell syntax, first defined in csh or tcsh, AFAIK. ash is a pure bourne shell with next to no extensions. Using '~' in a shell script is non-portable. Thanks, there is always something new to learn :-) Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.rules - Enabling shared libXt finally?
Hi all,
What we would need is a startup function which replaces pointers to the
importlib _XtInherit to the pointer of _XtInherit from the dll.
func reloc_addr[] = { };
unsigned reloc_addr_size = ...;
__startup_relocate(void) {
unsigned i;
func real_func = dlsym(cygXt.dll, _XtInherit);
for (i = 0; i reloc_addr_size; i++)
*(reloc_addr[i]) = real_func;
}
This must be added to libXt.dll.a and the linker must fill the reloc_addr
array.
I've found some time to take a look at this problem and it seems as I've got
a solution, which is documented below.
Could you please give this a try ?
cheers
Ralf
/*
/*
* The Symbol _XtInherit is used in two different manners. First it could be
used as a
* generric function and second as an absolute address reference, which will
be used to
* check the initialisation process of several other libraries. Because of
this the symbol
* must be accessable by all client dll's and applications.
* In unix environments this is no problem, because the used shared
libraries format (elf)
* supports this immediatly.
* Under Windows this isn't true, because a functions address in a dll is
different from
* the same function in another dll or applications. The used Portable
Executable
* File adds a code stub to each client to provide the exported symbol name.
This stub
* uses an indirect pointer to get the original symbol address, to which is
then jumped to,
* like this example shows:
*
* --- client --- --- dll
* ...
* call foo
*
* foo: jmp (*_imp_foo) foo:
* nop
* nop
*
* _imp_foo: .long index of foo in dll export table, is set to the real
address
* by the runtime linker
*
* Now it is clear why the clients symbol foo isn't the same as in the dll
and we can think
* about how to deal which this two above mentioned requirements, to export
this symbol to
* all clients and to allow calling this symbol as a function.
* The solution I've used exports the symbol _XtInherit as data symbol,
because globale data
* symbols are exported to all clients. But how to deal with the second
requirement, that
* this symbol should be used as function ? The Trick is to build a little
code stub in the
* data section in the exact manner as above explained. This is done with
the assembler code
* below.
*
* References:
* msdn http://msdn.microsoft.com/msdnmag/issues/02/02/PE/PE.asp
* cygwin-xfree: http://www.cygwin.com/ml/cygwin-xfree/2003-10/msg0.html
*/
libtest-1.tar.gz2
Description: Binary data
lib_xt.patch
Description: Binary data
AW: AW: Enabling SHM support in default build of XWin.exe
Hi Charles, ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. I think that you *should* use the DLL. And add cygipc to the setup.hint requires: of XFree86. Not because I think that everyone should or will 'turn on' the daemon, but because: you can't use libtool to make a DLL that has static dependencies (without heroic effort). Now, I know that XFree86 does not use libtool, but maybe I want to build gtk or something that (a) does, and (b) links to XFree86 libs. Since, in this scenario, the XFree86 libs will have a link time dependency on libcygipc.a -- I won't be able to build a DLL version of gtk (without heroic effort). What's the support issue you're worried about, Ralf? One more requires: library? When Harold is busy spinning out expat, fontconfig, and freetype -- what's one more? I forgot that the standard cygwin libtool has this limitation (I`m living on the kde [=older libtool release] side of libtool which uses a pass_all lib filter and you're right that it is easier to maintain one package (cygipc) as to recompile every package which is linked to the static cygipc lib on every new cygipc release. Thanks for pointing this out. ;-) Ralf
AW: IPC/SHM is now supported by default in xoncygwin HEAD CVS tree
Hi Harold, I just checked in changes to the MIT-SHM (xc/programs/Xserver/Xext/shm.c) and XFree86Bigfont (xc/programs/Xserver/Xext/xf86bigfont.c) extensions that disable SHM support when the Cygwin IPC daemon is not running. This allows IPC/SHM support to be enabled by default in Cygwin/XFree86. I tried to define the functionality of an OS-specific SHM support check as best I could, which resulted in adding a new function called OsVendorShmCheck (). This new OsVendorShmCheck function is called from shm.c and xf86bigfont.c when DDXOSSHMCHECK is defined. This system was designed to work like DDXOSVERRORF and OsVendorVErrorF (), for example. this is obviously the right way, I have seen the related patches for ...BSD, but doesn't know who to deal with. Thanks for this efforts. There will be a new Server Test Series release sometime tomorrow that includes this new functionality. I assume that the current xlib releases are linked without shm support ? Then the new features of the Xwin Test server will only be usable if at least the X11 and Xext libs are compiled with shm support. Ralf
AW: Enabling SHM support in default build of XWin.exe
Hi Harold, Ralf Habacker sent some patches on 2003/09/05 that I am working on getting committed to the XFree86 CVS tree. Those two patches are here: http://cygwin.com/ml/cygwin-xfree/2003-09/msg00092.html http://cygwin.com/ml/cygwin-xfree/2003-09/msg00090.html I have opened Bug 698 in XFree86's Bugzilla to track the fixing of the xf86bigfont extension initialization: http://bugs.xfree86.org/show_bug.cgi?id=698 After Bug 698 is committed I will be adding a function (from Ralf's patches) to XWin.exe to check whether or not the IPC daemon is running, then I will be adding a call to that function in the initialization of the SHM and xf86bigfont extensions (again, per Ralf's patch). Thank you for doing this. I was very busy in the last time with real work and I have used the spare time checking possible side effects relating to this issue. For the results see below. This should result in a build of XWin.exe that supports SHM when the IPC daemon is running, but is not hindered when the IPC daemon is not running. ... if linked to the static ipc-library. Using the cygipc dll results in an additional runtime dependency, which will produce windows runtime linking errors if the cygipc package isn't installed, which will produce more support noise dealing with this issue. Using the static library avoids this problem. Using the static library may cause a recompile of the x libs with a newer cygipc release in case the communication protocol between the ipc client and server changes, but I doubt that this will be happen, because the cygipc library is stable and full working. (Im using the static cypipc library for at least two years with no problems) This will be a nice addition, as it will allow Ralf to stop distributing ancient copies of XWin.exe for KDE on Cygwin. :) nice to hear. My one question is this: KDE on Cygwin (last I checked) is also distributing a handful of X libraries (X11?) that need SHM support as well, can SHM be dynamically enabled/disabled for these libraries, or are they going to have to be built in two different flavors still? Currently the Xext and the X11 libray are using shm related functions, for which I have done a little research with the results mentioned below. The result in short is, there is no need to build in two different flawors, using the static cygipc library. 1. lib/xext/Xshm.c All shm related functions are checking the MIT-SHM extension with the XExtCheckExtension macro. see http://www.atomised.org/docs/XFree86-4.2.1/XShm_8c-source.html 2. lib/X11/Font.c _XF86BigfontCodes checks the XF86BigFont server extension before using any shm code see http://www.atomised.org/docs/XFree86-4.2.1/lib_2X11_2Font_8c-source.html line 00352 ff The other libraries of the kde-x-1.3 package which you are refering are obsolate: libXft: - added qt3 referenced symbols XftGlyphLoad XftGlyphCheck XftFreeTypeGlyphExists XftFreeTypeOpen XftFreeTypeClose XftRenderString16 - these symbols are exported by default since 2002/09/18 libXext: - added shared memory relating symbols (XShm..) to the list of exported symbols - these symbols are exported by default in future libICE: - removed 5 seconds delay in libICE if file attributes don't match - fixed in 2002/09/18 Hope that helps Ralf
AW: [PATCH] package base-files: fix no global set of profile.d settings
Hi Igor, This has already been reported (and should be fixed in the next release of base-files). You should be able to find the relevant messages in the cygwin-apps archives. FYI, your patch is not space-in-filename-friendly. thanks for this note, I will wait for the next release. Could anyone say, when this release will be available ? Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
[PATCH] package base-files: fix no global set of profile.d settings
Hi, the base-files package release 2.2-1 contains an error, which prevents global setting environment vars of profile.d scripts. The problem is in the line /bin/find /etc/profile.d -iname '*.sh' -type f | while read f; do the pipe seems to create a subshell, which limits the live time of the environment vars of the profile.d scripts to the end of the done statement. (see below) # Run all of the profile.d scripts # Note that these are supplied by separate packages /bin/find /etc/profile.d -iname '*.sh' -type f | while read f; do if [ -f $f ]; then . $f fi done ## here no profile.d env vars set Cheers Ralf ChangeLog 2003-08-23 Ralf Habacker [EMAIL PROTECTED] * etc/defaults/etc/profile: Fix problem not setting environment vars through profile.d scripts. $ diff -up etc/defaults/etc/profile.old etc/defaults/etc/profile --- etc/defaults/etc/profile.old2003-09-15 14:19:46.0 +0200 +++ etc/defaults/etc/profile2003-09-15 14:20:14.0 +0200 @@ -47,7 +47,7 @@ fi # Run all of the profile.d scripts # Note that these are supplied by separate packages -/bin/find /etc/profile.d -iname '*.sh' -type f | while read f; do +for f in `/bin/find /etc/profile.d -iname '*.sh' -type f`; do if [ -f $f ]; then . $f fi -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: !RE: [PATCH] gcc3/ld patch for direct-linking-to-dll andauto-importsupport
I've tried that with your testcase and it seems to work. What gcc release you are using ? I tested with mingw builds of 3.3.1 and last weeks GCC-head (3.4). They put readonly data into .rdata$ sections if -fdata-sections but in .text otherwise. You're correct, though, it is is different in 3.2.x It seems that gcc3.2 (which is the recent cygwin release) does not support this. (See the ! below) Are there any other gcc options to archive this ? Not that I know of. A -mrdata-in-rdata :) switch would be handy. What should we do ? 1. wait until gcc 3.3 is in the cygwin net distribution and forgot this patch. 2. Apply this patch as it is. 3. Extend this patch with .rdata$ support like you have done and apply this all to ensure propper working for current and further gcc3 release. I would prefer solution 3. Any objectivies ? Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.3-1
Hi Harold,
What do you mean? Do you mean that even after adding a call to check if
shm is supported and running that the extension is still installed, even
if you return?
Or do you mean that looking at the existing code shows
that they were never checking for shm support in the first place?
this one.
Harold
--- old ---
void
XFree86BigfontExtensionInit()
{
if ((extEntry = AddExtension(XF86BIGFONTNAME, /* add extension */
.. /* check for shm support and return if isn't
avaliable */
--- new ---
.. /* check for shm support and return if isn't
avaliable */
if ((extEntry = AddExtension(XF86BIGFONTNAME,/* add extension */
Cheers
Ralf
!RE: [PATCH] gcc3/ld patch for direct-linking-to-dll and auto-importsupport
Hi, From: Nick Clifton nickc at redhat dot com Hi Ralf, while compiling trolltechs qt/xfree library with gcc3 (3.2x) on cygwin I recognized, that the auto-import stuff in combination of recent ld does not work in case of const variables in a dll when using direct linking to a dll, because gcc put those variables into a readonly, that means the .text section. The patch and a testcase is appended. A documentation could be found in the patch file. Are you sure that the current linker does not work ? When I tried it, using the test case you supplied, but without the patch applied, I got this: % make ../gcc/g++ -B ../gcc/ -g -save-temps -c -o dll.o dll.cc ../gcc/g++ -B ../gcc/ -g --shared -L ../i686-pc-cygwin/newlib -L ../i686-pc-cygwin/libstdc++-v3/src/.libs dll.o -o dll.dll ../gcc/g++ -B ../gcc/ -g -save-temps -c -o client.o client.cc ../gcc/g++ -B ../gcc/ -g -o client client.o -L ../i686-pc-cygwin/newlib -L ../i686-pc-cygwin/libstdc++-v3/src/.libs -L. -ldll Info: resolving _var by linking to __imp__var (auto-import) Info: resolving test::var by linking to __imp___ZN4test3varE (auto-import) There must be four auto imported vars. Yes, but try running ./client.exe. Since the const data variables are in .text section they are treated as functions, not data. They are imported without warning, but not as data. Ralf, what about a less intrusive approach? Compile dll code with -fdata-sections. This will put const data in .rdata$foo sections. Then, make pe_implied_import_dll() scan .rdata as well as .data and .bss. for data symbols I've tried that with your testcase and it seems to work. What gcc release you are using ? It seems that gcc3.2 (which is the recent cygwin release) does not support this. (See the ! below) Are there any other gcc options to archive this ? $ gcc --version gcc (GCC) 3.2 20020927 (prerelease) $ make g++ -save-temps -fdata-sections-c -o dll.o dll.cc $ less dll.s .file dll.cc .globl _var .section.data$var,w .align 4 _var: .long 1 .globl _constvar !.section.text$constvar, .align 4 _constvar: .long 2 !.section.text$_ZZ4funcvE14staticconstvar, .align 4 _ZZ4funcvE14staticconstvar: .long 2 .text .align 2 .globl __Z4funcv .def__Z4funcv; .scl2; .type 32; .endef __Z4funcv: LFB1: pushl %ebp LCFI0: movl%esp, %ebp LCFI1: subl$4, %esp LCFI2: movl$3, -4(%ebp) movl$1, %eax leave ret LFE1: .globl __ZN4test3varE .section.data$_ZN4test3varE,w .align 4 __ZN4test3varE: .long 4 .globl __ZN4test14staticconstvarE !.section.text$_ZN4test14staticconstvarE, .align 4 __ZN4test14staticconstvarE: .long 5 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin 1.5.3-1
Ralf --
What happens when you run your cygipc-based build of X11, but do not
have the ipc-daemon running? You can't run KDE, of course, but does the
Xserver itself still work properly? Can non-KDE X apps work?
Xfre has build in support for disabling XIT-SHM support in cases the kernel does
not support it.
See http://www.atomised.org/docs/XFree86-4.2.1/shm_8c-source.html
xc/programs/Xserver/xext/shm.c
snip
void
ShmExtensionInit()
{
ExtensionEntry *extEntry;
int i;
#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
if (!CheckForShmSyscall())
{
ErrorF(MIT-SHM extension disabled due to lack of kernel support\n);
return;
}
snip
Because the cypipc produces a valid return code ENOSYS in cases the ipc-daemon isn't
available,
see http://www.cygwin.com/ml/cygwin/2002-11/msg00136.html, there is only a simple
checker functions needed to check the state of the ipc-daemon and enable/disable shm
functions.
The appended patch implemented this support for the xfree server.
See the result:
cd ~/src/xc/programs/Xserver
$ killall ipc-daemon
$ ./XWin.exe
$ xdpyinfo | grep MIT-SHM
$ killall XWin
$ ipc-daemon
$ ./XWin.exe
$ xdpyinfo | grep MIT-SHM
MIT-SHM
Hope that helps
cheers
Ralf
--
Chuck
Harold L Hunt II wrote:
Well, that makes it easy. SHM will not be supported by this new build.
Harold
Christopher Faylor wrote:
On Thu, Sep 04, 2003 at 04:45:34PM -0400, Harold L Hunt II wrote:
I am not sure. How automagically is the IPC daemon installed? If
it requires user intervention, then we cannot really have XShm in the
default install.
You could make it a setup.hint dependency, of course, but that's only
half the battle. The next step would be to get the cygipc daemon
started. I don't think you want to go through that pain unless there is
a clean fallback for when cygipc isn't working right.
xext_shm.patch
Description: Binary data
RE: cygwin 1.5.3-1
Hi all,
The appended patch implemented this support for the xfree server.
I've found that the XFree86-Bigfont extension is also shm related, which is
fixed by the appended patch.
As I have looked into this code I was wondering about the extension
initialisation code, which doesn't work as expected.
It add's the extension regardless of if shm is available or not.
--- old ---
void
XFree86BigfontExtensionInit()
{
if ((extEntry = AddExtension(XF86BIGFONTNAME, /* add extension */
.. /* check for shm support and return if isn't avaliable */
--- new ---
.. /* check for shm support and return if isn't avaliable */
if ((extEntry = AddExtension(XF86BIGFONTNAME,/* add extension */
Cheers
Ralf
xext_xf86bigfont.patch
Description: Binary data
[PATCH] gcc3/ld patch for direct-linking-to-dll and auto-import support
Hi while compiling trolltechs qt/xfree library with gcc3 (3.2x) on cygwin I recognized, that the auto-import stuff in combination of recent ld does not work in case of const variables in a dll when using direct linking to a dll, because gcc put those variables into a readonly, that means the .text section. The patch and a testcase is appended. A documentation could be found in the patch file. A binary update (only containing ld) could be found here: http://kde-cygwin.sourceforge.net/snapshots/ld-gcc3-const-var-patch.tar.bz2 Cheers Ralf ld-gcc3-const-var-patch-testcase.tar.bz2 Description: Binary data ld-gcc3-const-var-patch.patch Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: XWinrc configurable server (menus/icons)
Hi Harold, If my IP is w.x.y.z vs. my loopback of 127.0.0.1, how is one of these using unix domain sockets and the other using tcp/ip? you're right, the answer is off-topic for this issue. I had read a note about using DISPLAY=:0, which means using unix domain socket and for that my answer was target. I only choosed the wrong mail. Sorry for confusing. Ralf
RE: cygwin as a replacement for explorer.exe
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Igor Pechtchanski Sent: Saturday, August 09, 2003 10:29 PM To: Sal Cc: [EMAIL PROTECTED] Subject: Re: cygwin as a replacement for explorer.exe On Sat, 9 Aug 2003, Sal wrote: Is it possible to use Cygwin and it's respective X server as a replacement shell for explorer.exe? Sal I think you're asking multiple questions at once here. I'll try to answer some of them: FYI, I use Cygwin (bash) as a replacement for the Explorer file manager, for things like getting directory listings, launching programs (using Windows associations too, with cygstart), and keeping track of processes (even Windows ones, using ps -W). It's adequate for most of my daily needs. If you want a graphical file manager, take a look at the KDE for Cygwin suite of tools. For KDE see http://lists.kde.org/?l=kde-cygwinm=103072530327420w=2. General Informations about KDE/cygwin could be found on http://cygwin.kde.org You can get more information on that by asking on the cygwin-xfree list. If you're asking whether you can replace the Explorer desktop, taskbar, and window manager with Cygwin tools/programs, I'm not sure if it's possible This is one of the goals of the KDE/cygwin project. Cheers Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin as a replacement for explorer.exe
If you want a graphical file manager, take a look at the KDE for Cygwin suite of tools. For KDE see http://lists.kde.org/?l=kde-cygwinm=103072530327420w=2. General Informations about KDE/cygwin could be found on http://cygwin.kde.org Thanks for the pointer. You can get more information on that by asking on the cygwin-xfree list. If you're asking whether you can replace the Explorer desktop, taskbar, and window manager with Cygwin tools/programs, I'm not sure if it's possible This is one of the goals of the KDE/cygwin project. I highly doubt it. If you read on further in my message than the part you quoted, you'd see that I mentioned controlling and switching to/from Windows programs. If that is the goal of KDE/Cygwin, then I completely misunderstood what it's about. As I understand it, it's a desktop environment for interfacing with X programs only (i.e., Cygwin or remote ones), but not local Windows programs. Does the project *really* plan to support, for example, a system-tray replacement showing the mouse driver icon? If so, *why*? (Just to show we can is as good a reason as any, The KDE/cygwin efforts are based on the fact, that for many people switching to linux from windows on the deskop isn't possible yet because of acceptance and training costs for the new applications. Our roadmap is to introduce KDE applications (along with the cygwin based command line) application on windows (at first xfree based, at last without xfree) so that the windows user could get familiar with KDE (and linux), which increases the user and developer base for such applications. The more such applications are running under windows, the easier is to introduce for example the KDE desktop as explorer replacement or other main KDE applications like Koffice, Kdevelop and so on. If KDE is widly used and accepted by windows users, the way replacing explorer with the KDE desktop isn't very far. So if the whole desktop is KDE based on windows, the additional task replacing the kernel by linux seems much nearer. If KDE/cygwin is a mostly complete desktop replacement for explorer and friends, than it should integrate native windows applications (1) into kde's startmenu (for example the control panel items) and (2) integrate running native applications into the KDE taskbar and task switcher. For (1), I have done a study and already working alpha release of the windows control panel items integration which creates related kde startmenu entries (desktop files). For (2): There are plans to extend kicker (kde's taskbar application) to recognize running native windows applications and to display it into the taskbar. This seems not to be a very hard job. So why should adding system tray icons not be possible ? Let me tell you some histories of this project, so you can imagine what going on: I have started in 2001 Mai with kde1/cygwin/xfree, one year later released qt2/cygwin/xfree and kde2/cygwin/xfree and this year qt3/cygwin/xfree and kde3/cygwin/xfree. November 2002 a native port of qt2 has been started and now the native qt3 gpl port is about 85% ready, which I have never believed before. On the linuxtag dvd this year a complete cygwin and KDE/cygwin release along a recent knoppix release was distributed. Klaus Knopper, who has build this dvd said, that they had burned 5000 dvd's and they would need 1000 more to still all the needs. In August 22-24, on the KDE developer conference in Nove Havre one session is about the KDE/cygwin state and how to prepare the KDE libs to support a native windows based KDE port, which I have never believed before too. So when I see this things happens, I could believe that we have a native kde 3 cygwin release based on in the beginning of the next year and implementing(1) and (2) would only a question of time. And last, Yes, there are some already known performance issues with cygwin like fork, unix domain sockets and file io, but I'm sure, this will be captured by the time. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: XWinrc configurable server (menus/icons)
Hi all, The most recent patch looks pretty good from your description. c) Replaces %display% with 127.0.0.1:display.0 in commands Huh, I was going to say that %display% should be replaced with 127.0.0.1:0.0, but then I remembered that we know the 0.0, but we don't know that the user connected via 127.0.0.1. However, should we just choose to replace display with 127.0.0.1:d.s where d is display and s is screen? I know that some users report better performance when using their actual ip instead of lookback for DISPLAY... ... because the performance of cygwin's tcp implementation is more than twice as much as the unix domain implementation. I assume that this is caused by the additional security and emulation stuff overhead, which is needed to implement unix domain sockets on top of tcp sockets. See http://sources.redhat.com/ml/cygwin/2002-01/msg01719.html for further details. Ralf
RE: [ANNOUNCEMENT] Server Test 95
Hi, there is a little problem with gcc 2.95.x. In some files I've got a compiling error like mentioned below: wingc.c: In function `winValidateGCNativeGDI': wingc.c:155: parse error before `fDebugProcMsg' wingc.c:156: `fDebugProcMsg' undeclared (first use in this function) wingc.c:156: (Each undeclared identifier is reported only once wingc.c:156: for each function it appears in.) make: *** [wingc.o] Error 1 The reason is, that gcc2 is not able to deal with variable definitions after code in a function. A workaround is to change the lines - DEBUG_FN_NAME(winSetSpans); - DEBUGVARS; - DEBUGPROC_MSG; into + DEBUGVARS; + DEBUG_FN_NAME(winSetSpans); + DEBUGPROC_MSG; Cheers Ralf Changelog 2003-08-04 Ralf Habacker [EMAIL PROTECTED] * winfillsp.c(winFillSpansNativeGDI), * wingc.c(winValidateGCNativeGDI), * winsetsp.c(winSetSpansNativeGDI): fix gcc2 compiling problems. diff -up xwin95_org/winfillsp.c xwin95/winfillsp.c --- xwin95_org/winfillsp.c 2003-07-31 00:34:53.0 +0200 +++ xwin95/winfillsp.c 2003-08-04 10:01:24.0 +0200 @@ -56,8 +56,8 @@ winFillSpansNativeGDI (DrawablePtrpDraw HDC hdcStipple = NULL; BYTE *pbbitsFilledStipple = NULL; int iX; - DEBUG_FN_NAME(winFillSpans); DEBUGVARS; + DEBUG_FN_NAME(winFillSpans); DEBUGPROC_MSG; /* Branch on the type of drawable we have */ diff -up xwin95_org/wingc.c xwin95/wingc.c --- xwin95_org/wingc.c 2003-07-31 00:34:54.0 +0200 +++ xwin95/wingc.c 2003-08-04 10:01:28.0 +0200 @@ -151,8 +151,8 @@ winValidateGCNativeGDI (GCPtr pGC, PixmapPtrpStipple = NULL; winPrivPixmapPtr pStipplePriv = NULL; int i; - DEBUG_FN_NAME(winValidateGC); DEBUGVARS; + DEBUG_FN_NAME(winValidateGC); DEBUGPROC_MSG; /* Branch on drawable type */ diff -up xwin95_org/winsetsp.c xwin95/winsetsp.c --- xwin95_org/winsetsp.c 2003-07-31 00:34:54.0 +0200 +++ xwin95/winsetsp.c 2003-08-04 10:01:50.0 +0200 @@ -52,8 +52,8 @@ winSetSpansNativeGDI (DrawablePtr pDrawa BITMAPINFOHEADER *pbmih; HBITMAP hBitmap = NULL; HBITMAP hbmpOrig = NULL; - DEBUG_FN_NAME(winSetSpans); DEBUGVARS; + DEBUG_FN_NAME(winSetSpans); DEBUGPROC_MSG; /* Branch on the drawable type */
RE: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
#ifdef SUNSHLIB
/*
* _XtInherit needs to be statically linked since it is compared against as
* well as called.
*/
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#define _XtInherit __XtInherit
+ #elif defined(CYGWIN)
+ void (_XtInherit)(void) = __XtInherit;
+ #define _XtInherit __XtInherit
#endif
With this way we have a symbol which contains the address of the XtInherit
function in libXt and is directly exported. This requires the pseudo-reloc
feature of ld.
Why ? Does client code access _XtInherit+offset at any place ? Only in that
case the pseudo-reloc stuff is needed.
Ralf
RE: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
ago
BTW: there are some design problems with the shared library.
snip
This test is also done in other shared libraries. On linux (and most unices)
there is no problem with this. But on windows the symbol XtInherit in the
other library points to the import table and is different to the pointer
stored in the struct. The comparisation will not work.
Do you have really tried this ?
On the assembly level every reference of the above symbol uses the same
symbolname, which is the address of the stub coming from the libxxx.dll.a or any
other import library (or build internally by ld in case of using the
direct-to-dll-linking feature see info ld -machine depended-Win32).
I have build a real working example with a symbol of libX11, which seems to be
the same
#include stdio.h
void _Xwcsncmp(void);
typedef struct {
void (*func)(void);
} Str ;
Str x = { 0};
/*And on some places they test if x.func is set: */
main()
{
if (x.func != _Xwcsncmp)
printf(test failed\n);
else
printf(test passed\n);
x.func = _Xwcsncmp;
if (x.func != _Xwcsncmp)
printf(test failed\n);
else
printf(test passed\n);
}
$ gcc test.c -save-temps -lX11 -L/usr/X11R6/lib
$ ./a.exe
test failed
test passed
Cheers
Ralf
RE: [XFree86-4.2.0] Now that we have an improved ld, please make libXt a shared library.
Hi Alexander,
for libXt it uses the direct address. For every other library using
the libXt.dll it uses the address from the stub.
I see, this is another case. Please take a look into xc/lib/xt/Initialize.c and
xc/lib/xt/sharedlib.c which provides such a case for another os. I don't
understand the xfree build system very well, so I can't provide a working
solution for this, but in fact _XtInherit() should be located in the xt import
library, which references __XtInherit() which is located in the real xt dll.
Cheers
Ralf
snip
#ifdef SUNSHLIB
/*
* _XtInherit needs to be statically linked since it is compared against as
* well as called.
*/
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#endif
In sharedlib.c there is similar code
snip
#ifdef SUNSHLIB
void _XtInherit()
{
extern void __XtInherit();
__XtInherit();
}
#define _XtInherit __XtInherit
#endif
void _XtInherit()
{
XtErrorMsg(invalidProcedure,inheritanceProc,XtCXtToolkitError,
Unresolved inheritance operation,
(String *)NULL, (Cardinal *)NULL);
}
RE: Source code for binaries offered at http://thinstall.com/ ?
Hi http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites The link is out of date, the new one is http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites Cheers Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Source code for binaries offered at http://thinstall.com/ ?
Hi, On Mon, Jul 28, 2003 at 08:37:43PM +0200, Ralf Habacker wrote: http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites The link is out of date, the new one is http://www.gnu.org/licenses/gpl-faq.html#TOCSourceAndBinaryOnDifferentSites The link is not out of date. The link you are referring to is a different link to the same topic within the table of contents. your right, I have overseen this additional link. Thanks for pointing to. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: [SEMI-OFFTOPIC] Request for Ralf Habacker
Ralf, I appreciate the acknowledgement on your kde-cygwin web site but I really would rather not have my email address available on your acknowledgement page. I know that Corinna probably feels the same way and I suspect that Charles Wilson, Egor Duda, and Robert Collins probably all would rather not have their addresses available for spammers to harvest. There are a few other people displayed there as well. I can't speak for them but I would assume that most would feel similarly. I don't think there is any reason why users of kde-cygwin would need to contact any of us personally, so I would suggest just referring people to the cygwin web site if they have general questions or concerns. I would appreciate your prompt attention to this matter. I see several attempts by spammers to send email to the address that you display on your web site, so I know that your site is currently being harvested. -- No problem. The email adresses are removed. Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: RE: qt3 on cygwin
Hi, I tried to compile qt3 from kdesygwin.sf.net but i've maybe done a mistake while retrieving the files from cvs indeed in my package (retrieved with cvs) there's no header in include in a normal qt x11 there are sym links for ex : include/qmap.h - ../src/tools/qmap.h See the qt-3 compiling instruction on http://cywin.kde.org i'm going to get those files again with cvs, hoping i'll suceed (maybe cvs has not set those sym links) There is a mailing list for qt3/cygwin see http://cygwin.kde.org i imagine getting x11/qt from trolltech and compiling it with cygwin it will generate errors, nobody tries ? This will not work, try the patched qt-3 sources on http://cygwin.kde.org Ralf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: qt3 on cygwin
Hello i'm trying to compile qt3.1.0 on cygwin as said in http://kde-cygwin.sourceforge.net/qt3-win32/compiling.php but i get errors (impossible to find headers) has someone compiled qt3.1.0 on cygwin ? The qt3-win32 section covers the native port of qt on cygwin without using xfree (but still using cygwin), which is in an early state and may not compile out of the box. If you are trying to compile the xfree version of qt3/cygwin you should read http://kde-cygwin.sourceforge.net/qt3/compiling.php. Cheers Ralf
RE: Problem in compiling : cannot find -ldl
Elfyn McBratney wrote:
Here is the line for the compilation :
gcc -o wish.exe OBJ/wish.o OBJ/calculPosition.o
OBJ/calculVisibiliteCmd.o -L/usr/lib -L/usr/X11R6/lib
-ltk -ltcl -ldl -lX11 -lm
and it produces this error :
/usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../i686-pc-cygwin/bin/ld
: cannot find -ldl
libdl is a linux'ism. You don't need it. We don't have it :-) Just
remove '-ldl' from the Makefile or link line.
Hmmh, is cygwin a unix emulation environment ? Usually in linux libdl contains
symbols for dynamic loading of shared libraries. In cygwin this is provided by
the libcygwin.
To ensure linux compatibility there are additional import libraries like
libpthread.a providing symbols of the cygwin dll, so that users does not have to
deal with the specific cygwin implementation.
But one thing I never understood with cygwin is, why libdl.a isn't provided in
the way libpthread does.
I have encountered several linux libs, which requires this libraries, so that I
have to add a symbolic link from /lib/libcygwin.a to /lib/libdl.a on any
machine, which does compiling such libs.
If anyone is interested to add a compatibility library for libdl.a, apply the
following patch to the cygwin sources.
Cheers
Ralf
-
2003-07-11 Ralf Habacker [EMAIL PROTECTED]
* Makefile.in (libdl.a): provide unix compatibility library
for dlopen related functions.
-
$ diff -up Makefile.in.orig Makefile.in
--- Makefile.in.orig2003-07-11 22:31:10.0 +0200
+++ Makefile.in 2003-07-11 22:32:09.0 +0200
@@ -233,7 +233,7 @@ NEW_FUNCTIONS:=regcomp posix_regcomp \
API_VER:=$(srcdir)/include/cygwin/version.h
PWD:=${shell pwd}
-SUBLIBS:=libpthread.a $(PWD)/libm.a libc.a
+SUBLIBS:=libpthread.a libdl.a $(PWD)/libm.a libc.a
EXTRALIBS:=libautomode.a libbinmode.a libtextmode.a
INSTOBJS:=automode.o binmode.o textmode.o
TARGET_LIBS:=$(LIB_NAME) $(SUBLIBS) $(CYGWIN_START) $(GMON_START) $(LIBGMON_A)
$(SUBLIBS) $(INSTOBJS) $(EXTRALIBS)
@@ -379,10 +379,13 @@ shared.o: shared_info_magic.h
libpthread.a: speclib cygwin.def pthread.o thread.o
/bin/sh ${word 1, $^} $@ ${NM} ${DLLTOOL} ${AS} ${wordlist 2, 99,
$^}
+libdl.a: speclib cygwin.def dlfcn.o
+ /bin/sh ${word 1, $^} $@ ${NM} ${DLLTOOL} ${AS} ${wordlist 2, 99,
$^}
+
$(PWD)/libm.a: speclib cygwin.def $(LIBM)
/bin/sh ${word 1, $^} $@ ${NM} ${DLLTOOL} ${AS} ${wordlist 2, 99,
$^}
-$(PWD)/libc.a: speclib cygwin.def $(PWD)/libm.a libpthread.a
+$(PWD)/libc.a: speclib cygwin.def $(PWD)/libm.a libpthread.a libdl.a
/bin/sh ${word 1, $^} -v $@ ${NM} ${DLLTOOL} ${AS} ${wordlist 2,
99, $^}
lib%.a: %.o
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: I am back
Hi Harold, Have you checked if xoncygwin (SourceForge CVS) has both of your patches applied? I think that I applied them both, but it would be nice if you could verify that I did. The patches were not directly applied... I looked at them and did the modifications by hand, adjusting a few things here and there, so a diff will help you but it won't be identical to your diff. Today I had already taken a look on the xoncygwin cvs and recognized this. It seems that all patches are applied. Thanks Ralf
RE: Memory access error in XWin -multiwindow
Ralf Habacker wrote: After installing this package, relink the Xserver with the following line: $ make LDFLAGS=-Wl,--whole-archive -Wl,-lmemwatch -Wl,--no-whole-archive I just noticed two little issue with linking xwin: 1. The above link line is a link line using default Makefiles, but unfortunally Xwin uses not this standard. So you have to use the following. make EXTRA_LOAD_FLAGS=-Wl,--whole-archive -Wl,-lmemwatch -Wl,--no-whole-archive -Wl, -debug XWin.exe 2. I have overseeen, that Xwin does not support stderr output, so there are not results for xwin. I've uploaded an updated mem_watch (release 1.1) to http://sourceforge.net/project/showfiles.php?group_id=27249. MEMWATCH_OUTPUT=/c/temp/test.log ./test Ralf
RE: Memory access error in XWin -multiwindow
Hi Biju, I am facing an issue of Memory access error in XWin -multiwindow mode see http://www.cygwin.com/ml/cygwin-xfree/2003-06/msg00294.html So Ralf pointed me to http://cygwin.com/ml/cygwin-xfree/2003-06/msg00162.html After seeing that patch, I have just gone thru XWin Source and found, at lot of place we call memory alloc and not testing the return value. I am attaching the list extracts from programs I dont know all of those will make any issue. I did not checked whether it is properly free()-ed You can try the mem_watch library on http://sourceforge.net/project/showfiles.php?group_id=27249. It allows checking of memory related calls on cygwin with minimal effort. After installing this package, relink the Xserver with the following line: $ make LDFLAGS=-Wl,--whole-archive -Wl,-lmemwatch -Wl,--no-whole-archive Then start Xwin and you can see all memory related calls and there calling address. See an example output below (you can get more informations through the INSTALL file of the memwatch release). $ ./test MemWatch hooks installed (set MEMWATCH=1 env var to enable debugging) Memory Checker report = number of calls: malloc : 3 calloc : 1 realloc : 0 free : 1 used memory : 350 unfree'd memory areas address sizecalladdr 0a040488 30000401afc 0a040448 2000401ac7 0a040460 3000401ad9 == 350 compile this application with debugging symbols and try addr2line to get the source line of the relating call addr2line -e ./test.exe calladdr May be that helps. Cheers Ralf
RE: E Z ? - Tried installing KDE and lost original windowing system
On Thursday, June 19, 2003, at 09:10 AM, Larry Hall wrote: Robert Pollard wrote: Hello all, I tried to install KDE and it wouldn't run after installation. I did all the post installation changes. It comes up with an error window saying The application failed to initialize properly (0xc022). Click on OK to terminate the application. This has happened every since I installed the KDE packages. I reversed all of the changes to get the original windowing system back and it still comes up with this error. Any ideas? Thanks for your time, Robert Pollard This may be a problem of execute permissions of dll's. See http://www.cygwin.com/ml/cygwin/2002-10/msg00616.html for more informations. Additional you can verify if the kde dll's have execution permissions. $ find /opt/kde3 -type f -name '*.dll' -ls or update all execute permissions immediatly $ find /opt/kde3 -type f -name '*.dll' | xargs chmod a+x $ find /opt/gtk -type f -name '*.dll' | xargs chmod a+x $ find /usr/local/lib/qt3mt/bin -type f -name '*.dll' | xargs chmod a+x Cheers Ralf
