Christopher Faylor schrieb:
> On Tue, May 30, 2006 at 09:18:56PM -0500, Yaakov S (Cygwin Ports) wrote:
> 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 discus
-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 applica
-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 <>
(gdb) run
(gd
-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
-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 exac
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 dl
-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.
>
-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 cur
-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 applic
-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 d
-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 p
-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'
-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 wrot
-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\tests>strace
>> mutex1n | grep C005
>> - --- Pr
ro 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:
ear 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/
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 k
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?
> >>
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+
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++ -
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
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 machin
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-portag
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
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 s
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 P
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 proble
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
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
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.
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 sta
Hi all,
yesterday I have downloaded a recent cygwin snapshot and tried with the coming
kde-cygwin 3.1.4. In the past I recognized, that running kde on cygwin is a
good stress test for the cygwin dll.
Please note that I'm still using cygipc for shared memory support, so I cannot
say anything
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
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
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.
$
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
>
> 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 lib
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: The
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
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=~:/us
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 anyo
. "$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/profil
> > > 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
Hi,
> > From: Nick Clifton
> >
> > 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
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
> > > 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-cygwin&m=103072530327420&w=2.
> >
> > General Informations about KDE/cygwin could be found on
http://cygwin.kde.org
Thanks for the pointer.
> > You c
> -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 p
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#TOCSourceAndBinaryOnDiffe
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:
> 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
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/qma
lic 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
---
> Gerrit P. Haase wrote:
> > Hallo,
> >
> > why is the MD5 check performed every time?
>
> A good question.
>
> > Because in the five minutes from now on, my packages
> > may be corrupted?
> >
> > How can I get rid of it?
>
> There is a command line option to disable: -5
>
But what about starting s
> If you have such great insight into this type of thing, it won't take
> you any time at all to duplicate. You've been complaining about this
> and other cygwin performance issues for months. Why don't *you* do
> something? I figured fork/exec/signals out from scratch. Certainly the
> brighte
> I don't have the code anymore
It's a pity, because everbody else has to start from scratch and couldn't take a
deeper look and perhaps find the problem.
Cheers
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Document
>> Having Mozilla itself running under Cygwin might not be useful
>> to a lot of people but the fixes that Cygwin might have to go
>> through to make this happen could pave the way for other X apps
>> that come later.
>
>like we have encountered while porting KDE to cygin/xfree.
>
I remember a very
Hi,
> Having Mozilla itself running under Cygwin might not be useful
> to a lot of people but the fixes that Cygwin might have to go
> through to make this happen could pave the way for other X apps
> that come later.
like we have encountered while porting KDE to cygin/xfree.
Cheers
Ralf
--
Hi
> First off, I have said it before and I'll say it again, Evolution from
> Ximian needs to be ported to Cygwin..
do you have heard from KMail or KOrganizer on cygwin/xfree.
Additional for the people who does not know that there is already an alternative
web browser: Konqueror from the kde-cyg
> am already running the ipc-deamon, no change, the problem seems to be
> with the qt-2-3.dll, if I tell cygwin to use that version, then, when I
> use the xclient, none of the kde icons appear
Do you have this problems with the qt-designer too ?
I haven't got this problems with the recent qt cvs
> is there a location to install cygwin with Gnome &/or kde as part of the
> package? I have looked around on the net, and the only info/help I can
> find is, have to install about 50 pieces of source for Gnome, and
> configuring X to work with KDE 2.0 seems to break using Xwin as a client
> connec
Hi all,
while porting arts 1.2.0 (=Advanced Realtime synth for kde) I've encountered a
dll loading problem loading (unter W2k verified with cygwin 1.3.21-1 and recent
snapshot).
The background:
The arts daemon tries to load an additional library with lt_dlopen (see the
backtrace below) and hangs i
> I just realized that libc.so on linux is just a linker script and
> that it is used to link both the shared and static parts of libc.
>
> So, in a similar vein, you could conceivably do something like this
> on cygwin:
>
> /* GNU ld script
>Use the shared library, but some functions are only
> Okay, I've actually looked at the patch now. Apparently I misunderstood.
>
> I thought this was a patch to enable using libtool to link against an
> outside shared library in which the implib was actually a symlink to a
> DLL -- which I didn't think would require much if any hacking with
> libto
> On Mon, Mar 10, 2003 at 08:13:16AM -0500, Charles Wilson wrote:
> >I didn't realize it was a patch to rip out all of the import-lib
> >building stuff, and replace it with the new link-to-dll support.
>
> I've been blissfully trying to avoid libtool discussions but I have to
> ask my standard ques
> > I can see many more source code changes.
>
> I think cgf meant that the only difference between this package, and
> straight-from-CVS binutils (20030307 snapshot) is the pseudo-reloc change.
>
> Certainly, the basic CVS source has had many many changes since
> 20021117. Including your direct-l
Hi
> I've made a new version of binutils available for installation.
> This version is a refresh from CVS on sources.redhat.com.
>
> This release has one minor change from Chuck Wilson to make
> --enable-runtime-pseudo-reloc the default for `ld'.
>
Are there no more changes in this release ? Wenn
Max Bowsher wrote:
>
> > I'm not quite sure rpm really is desirable for the Cygwin dist, unless it
> > was decided to transition to rpm packages exclusively once setup was
> > suitably adapted.
>
> Well, there are grand designs eventually to generalize setup so that it
> can accept tar.bz2 (or .cyg
> [BTW, Ralf, patches to libtool don't belong on cygwin-apps. It's not a
> packaging issue, a packaging-policy issue, nor a setup issue. This
> thread belongs on the main cygwin list.]
I apologize for this mistake. Sometime it seems that I have too many things in
my head. :-)
Ralf
--
Unsubs
> It's up to you -- that's why I coded the libtool changes so that your
> improvements could be a "drop in" fix. I think it'd be "nice" is file
> could tell me that a given file was an import lib or a (regular) lib,
> but it isn't necessary.
>
> There's certainly no rush.
I will see.
The problem i
> o speed problem with the internal "win32_libid()" routine is partially
> fixed -- approx 35% speedup. Ralf Habacker is working on some
> modifications to the official fileutils distribution (specifically,
> file.exe) that should allow an additional 8% speedup without a
>
> > Thanks for this additional note.
> >
> >>from a previous mail:
> >
> >>>So, it's important, Ralf, that your 'file' changes NEVER generate a
> >>>false positive (e.g. saying something is an import lib when it is not).
> >>> If your code generates a false negative (saying something is static
>
> > You may be right in this issue, but couldn't the symbol "_dll_iname" doesn't
> > change in future implementation too ? The important question seems
> to me like
> > this: [1] Which is the mostly stable identifier we build on ?
>
> filenames change because evil twisted pesky end-users change the
> Ralf,
>
> On Mon, Feb 17, 2003 at 11:40:44PM +0100, Ralf Habacker wrote:
> > > I found another bug (most likely introduce by me in a previous
> > > patch) when rebasing up and the DLL is already based at the
> > > requested address. The attached patch is o
> > Thats very bad.
> >
>
> Yeah. I don't know why these implibs need to declare these static
> structures; it's possible that w32api is just following the lead of the
> corresponding .lib files in the MSVC distribution.
>
> But, that's neither here nor there. IF these crossbreed implibs are
> de
>convenience libs do not count. You can still link a DLL with convenience libs,
because it is assumed that a true convenience lib is built by your project, for
your project, and only for your project -- it is not available to "outside
users" and therefore there can never be any mismatch between th
>>BTW: Do you know which libraries are also hybrid execpt of cygwin1.dll ?
>There are about a half-dozen in /usr/lib/w32api -- and worse, the static
members are "bad" variable types; if you make the static members part of the
DLL, then these vars can't be auto-imported without using pseudo-reloc
> >
> > > wasn't tight enough.
> > >
> > > My version:
> > >
> > > (char *)&relocp->SizeOfBlock < (char *)relocs + size
> > >
> > > seems to be.
> > >
> >
> > What was the problem with this guard:
>
> To which guard are you referring? Mine or yours?
>
> > Does it not fix the last entry of a re
> But, you'd still need to check all "static libs" to see if they are
> really import libs after all. The good news it that we expect this to
> happen only rarely: when an import lib is a "hybrid" lib with static
> objs "in front" --> the modified 'file' test incorrectly identifies it
> as a stat
> Applied, with the usual ChangeLog corrections.
Probably I will it learn at some time.
After looking in the sources, I have seen that you also have implementend the
intx_t types (uintx_t were already there), which otherwise would be my next
patch.
Thanks
--
Unsubscribe info: http://cygwi
> ARGH. This defeats the whole purpose of the policy change -- and it is
> a policy change driven by the libtool development. I don't want to
> support a forked version of libtool that differs from mainline on a
> basic policy issue.
>
May be, but like Max has stated, I don't like to be forced t
ed intinet_netof (struct in_addr);
-unsigned intinet_network (const char *);
+in_addr_t inet_netof (struct in_addr);
+in_addr_t inet_network (const char *);
char *inet_ntoa (struct in_addr);
#endif
ChangeLog
-
> Ain't gonna happen. Find me a faster way to distinguish between x86
> import libs and x86 static libs (and random-other-architecture libs of
> any sort), and I'll thank you.
>
see [1]
> But telling me that I must support a fundamental philosophical and not
> merely technical fork of libtool fo
> 1.4e isn't a specific version. It just means "some cvs checkout after the
> 1.4d release"
but this could be a long period: :-)
The recent devel libtool tells:
$ libtool --version
ltmain.sh (GNU libtool) 1.4e (1.1175 2003/01/01 01:57:46)
ltmain of recent kde from anoncvs.kde.org:
VERSION=1.4e
> From 'info libtool':
>
>`pass_all'
> will pass everything without any checking. This may work on
> platforms in which code is position-independent by default and
> inter-library dependencies are properly supported by the dynamic
> linker, for example, on DEC OSF/1 3
> Ralf -- please drop my 'final' script into one of your generated
> libtools and run your tests (what? rebuilding KDE?) on it, and let me
> know what you think. (Oh, and since (a) 'file' execution speed is
> invariant with target size, and (b) we match *DLL* and *executable*
> separately, if you
Hi Charles,
I've taken a deeper look into the libtool sources and found a hint relating to
the way other os do this checking, for example
libtool.m4.in
# AC_DEPLIBS_CHECK_METHOD
pass_all
gnu*)
irix5* | irix6* | nonstopux*)
linux*) (most hosts)
osf3* | osf4* | osf5*)
sco3.2v5*)
solari
> You never followed up on that.
Rebooting every time need very much time (about 10 minutes for me) and there is
an easier way to emulate that. I've written an applications which's allocate any
available memory. This removes all cached files' dll's and so one. I had similar
problems while inspecti
> Yes, Ralf, I know. This is like the sixth iteration trying to solve
> this problem. The very first attempt did what you suggest (only it is
> much much more complicated than you imply; you're overlooking a lot).
> However, that fix was unacceptable to the automake and libtool people.
> Hence,
Hi Chuck,
>3) What I did: create a binary wrapper -- an actual executable --
> named 'foo.exe' in the main build directory. It is NOT the real
> foo.exe. It simply exec's the shell script, which in turn sets up the
> environment and exec's the real .lib/foo.exe. Eventually, the 'set up
> th
I've updated libtool-devel to the 20030121 CVS, plus added a major
change of my own (inspired by Earnie Boyd and others on the libtool
mailing list) that "fixes" the 'relink exe's over and over and over'
problem on both mingw and cygwin.
[Skip to the last two paragraphs for the real import
>Currently it is a resourcen problem, that kde/qt isn't be distributed with the
>cygwin net release. I have all hands to do with the user support on the
>kde-cygwin mailing lists and foren and to deal with the basic stuff (ld,
>imagehelper,libtool,...), that there is no time to support the users i
> >GNOME-cygwin port: http://homepage.ntlworld.com/steven.obrien2/
> >KDE3-cygwin port: http://kde-cygwin.sourceforge.net/qt3/using.php
^^^
Currently kde2 is running, kde3 is in work.
> >
> >Would there be a chance to get these integrated into Cygwin distro?
> >Can any of the Cygwin core develo
Sorry my finger were pressing the send to key before this mail was ready.
> > Is this a bug or feature?
> >
> > $ cygcheck -c cygwin perl
> > Cygwin Package Information
> > Package Version
> > cygwin 1.3.17-1
> > perl5.6.1-2
This is a known issue with thi
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Volker Quetschke
> Sent: Wednesday, January 22, 2003 10:35 AM
> To: [EMAIL PROTECTED]
> Subject: Perl with -i option removes files
>
>
> Hi!
>
> Following szenario:
>
> $ echo abc > testfile
>
> $
> patience. cgf is the maintainer for binutils on cygwin, but I'm sure he
> has his hands full getting ready for the imminent 1.3.19 cygwin kernel
> release.
>
> BTW, Danny reported a problem with Fabrizio Gennari's "create an export
> section for .exe's" patch and relocatable linking. Danny sent
Hi all,
in december 2002 Charles Wilson and I had supplied an ld patch for the
auto-import from dll functionality.
For the kde-cygwin project we would like to use this new stuff in the near
future for the next qt3 release.
General there are two way to solve this:
Because we don't like to releas
Hi Chris,
1.
>I don't see how you could do that since the symbol is associated with an
>existing place in memory. We could put the whole function in a
>different segment but that's not the kind of solution I was thinking of.
2.
> I was thinking that there might be an unused attribute that could
>>
> >What about putting such symbols in another named text section, so that
> >ld would ignore them ?
>
> I don't see how you could do that since the symbol is associated with an
> existing place in memory. We could put the whole function in a
> different segment
I had in mind something like thi
> > Maybe the horse has left the barn already but it would have been nice
> > (tm) if these type of symbols were marked in some generic way so that
> > we wouldn't have to keep remembering to extend this table.
>
> I recall commenting on this aspect in a recent binutils thread in the
> cygwin lists
> > Interesting. The history is a little garbled (Steve Chamberlain didn't name
> > the project "Cygwin" and there was no magical decision made in 1999 to do
> > anything) but it's always nice to get exposure.
> >
> Perhaps you should send a correction to this magazine :-)
I think I have not the
1 - 100 of 224 matches
Mail list logo
