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
> 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
> 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
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
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
--
>> 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
> 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
> 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
> 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
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
---
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
> 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
> 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:
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
> -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
>
> > On Mon, Oct 07, 2002 at 12:35:02PM +0200, Ralf Habacker wrote:
> > > this patch add a unix like 'rc'-start script for the postgresql server.
> > >
> > > 2002-10-17 Ralf Habacker <[EMAIL PROTECTED]>
> > >
> > > rcp
> On Mon, Oct 07, 2002 at 12:35:02PM +0200, Ralf Habacker wrote:
> > this patch add a unix like 'rc'-start script for the postgresql server.
Original I had send this to cygwin-patches, which was of course a very bad idea.
Sorry all for this mistake.
Ralf
--
Unsubscr
Hi Jashon,
> > Thanks for the pointer. My main problem was that I had somehow gotten
> > a version of rebase that took different parameters (it's not the
> > Microsoft one--it may have come from the KDE site). The version from
> > your site is more like what I expected.
The basic functionality i
> This is the same old problem that has always existed with cygwin fork
> and perl, AFAICT. There is no guaranteeing that a dll which is loaded
> into a specific location in a parent will be loaded into the same
> location in the child.
>
> Cygwin tries to force loading in the proper place but so
> Ralf,
>
> On Mon, Oct 14, 2002 at 08:03:25AM +0200, Ralf Habacker wrote:
> > > My goal was to make my rebase as similar in usage to the Microsoft
> > > one as possible.
> > >
> > And what about Win ME ? How do you could archive your goal, when th
> Why does apache tries to load cygxml2-2.dll?
>
the php module uses this dll.
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.c
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:cygwin-owner@;cygwin.com]On Behalf
> Of Gerrit P. Haase
> Sent: Saturday, October 26, 2002 10:55 AM
> To: Ralf Habacker
> Cc: [EMAIL PROTECTED]
> Subject: Re: Apache doesn't run anymore with 1.3.14
>
&
> > > -Original Message-
> > > Isn't rebasing included in the mod_php dist anymore?
> > >
> >
> > It is in the distribution, so if someone have problems with
> rebasing, he should
> > use it.
> >
>
> ...
>
> > usr/lib/apache/new/libphp4.dll
> > usr/lib/apache/new/rebase.exe
> >
> > Ralf
> >
> So there is a PHP version for cygwin
> does it work ?
>
99%, only phpinfo() hangs reproducable while printing a specific module info.
> How do you install it ?
>
1. See /usr/doc/Cygwin/php-4.2.0-1.README after you have installed mod_php4 for
installing.
2. If you encounter rebasing problems, t
> > The absolute base address isn't the most important thing, the only
> thing which
> > is important to find a base address which isn't used by one of the
> applications
> > loaded dll's.
>
> yep, shouldn't we enforce some bash script that can detect such a
> "free" base address or modify Jason's
>
> > A first step in this direction is the list option -l which I have
> added to the
> > kde-cygwin's rebase, which is a fork of jason's one.
>
> any URL pointers? I'd like to check that in a free nano-second I get
> in the upcoming infinity :))
>
the recent version is bundled with the kdelibs pa
Hi all,
I've recognized some md5 differences on the various crypting tools between
cygwin and linux.
[1]openssl: echo "0123456789" | openssl dgst -md5
[2]md5sum: echo "0123456789" | md5sum
[3]php: echo '' | php -q
[4]postgre: select encode(digest('012
> -Original Message-
> From: Jason Tishler [mailto:jason@;tishler.net]
> Sent: Thursday, November 07, 2002 7:48 PM
> To: Ralf Habacker
> Cc: Cygwin
> Subject: Re: postgresql question
>
>
> Ralf,
>
> On Thu, Nov 07, 2002 at 03:18:38PM +0100, Ralf Haba
> Hi all,
>
> Is there a debug version of malloc for cygwin that I can link
> against? I am trying to track down a sneaky memory leak.
>
http://sourceforge.net/project/showfiles.php?group_id=27249&release_id=121299
Try this malloc debugging library and let me know if this helps.
I have used this
> On Fri, Nov 08, 2002 at 09:50:45AM +0100, Ralf Habacker wrote:
> > > -Original Message-
> > > From: Jason Tishler [mailto:jason@;tishler.net]
> > > Sent: Thursday, November 07, 2002 7:48 PM
> > >
> > But some pgcyrpto functions returns di
>
> Me too. Sorry, I don't know why the regression test fails for you.
Do you have done the test with the source of the recent cygwin release or are
you using a newer release from www.postgresql.org ?
(I'm using the first)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bu
Hi Jason,
> I would prefer to leverage off of Sergey's sysvinit package:
I have heard from this package, but hadn't any time to inspect whole details.
> The following is the only required diff (besides the expected ones) to
> PostgreSQL's contrib/start-scripts/linux:
Does that means the next po
> > before you are able to use php scripts which connect to a pgsql DB (of
> > course phpPgAdmin will do so) it is necessary to configure this module with
> > the appropriate flag (--with-pgsql) plus recompilation.
>
> this has been done for the php-4.2.0-1 release. PostgreSQL should be
> supporte
If s, than I will release a patched binutil > what means "recompiled" cygwin php
release?!
>
> Did you compile it on your own from a official source tree or
> recompiled the cygwin patched tree that is included in the distro?
>
The second.
Regards
Ralf
--
Unsubscribe info: http://cygwin.com
Hi Jason,
>
> Yes, unfortunately I am running WinME, so I downloaded the attachment to the
> above message. Unfortunately, the make fails as shown below.
>
Ups, sorry, there are symbolic link in the package, with files are not
distributed.
> Can anyone help me here, or point me to a binary distri
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf
> Of Gary Stainburn
> Sent: Monday, November 18, 2002 5:04 PM
> To: Ralf Habacker; cygwin
> Subject: Re: 3rd time lucky? Apache startup woes
>
>
> On Monday 18 November 2002 1
Hi all,
this thread I have found on [EMAIL PROTECTED]:
>
> I've experimented with using cygwin as my development environment...
>
> My initial goal was to compile using gcc, as we are using gcc in
> the MacOSX world. I ended up grabbing the qmake and moc from the KDE
> distribution to accomp
> what does ssp do?!
>
> Haven't seen about that beast before. Could someone enlight me
> please?!
>
from man ssp
SSP - The Single Step Profiler
Original Author: DJ Delorie
The SSP is a program that uses the Win32 debug API to run
a program one ASM instruction at a
this patch with recent qt-2/3 and kde2 sources without any
problems. A sample test case is appended too.
Please give this patch a try and report problems to me o0r to this list.
Thank you
Ralf Habacker
KDE on cygwin http://cygwin.kde.org
ld-auto-import-dll.patch
Description: Binary data
> On Mon, Nov 25, 2002 at 01:46:50PM +0100, Ralf Habacker wrote:
> >3. ld works more like the linux version. There are only static archives and
> >shared libraries which could be linked directly without the
> indirection of using
> >import libraries. This simplifies for
t; direct auto-import of dll's
>
>
> On Mon, Nov 25, 2002 at 11:50:13PM +0100, Ralf Habacker wrote:
> >Chuck Wilson wrote:
> >>Minor nit about patch format: watch out for your tab/indentation. It
> >>doesn't match the surrounding text in many cases.
> &
for performance reasons -
> > direct auto-import of dll's
> >
> >
> > On Mon, Nov 25, 2002 at 11:50:13PM +0100, Ralf Habacker wrote:
> > >Chuck Wilson wrote:
> > >>Minor nit about patch format: watch out for your tab/indentation. It
>
> >This and perhaps other libraries may be an exception, but couldn't this
> >splitted like linux does ? If I remember right, they uses a standard
> >lib like glibc, which may be a shared lib and some kind of startupcode
> >in an objectfile (static), which may be different for executable or
> >dl
> All well and good, Ralf, but Chris' comment grew out of your policy
> recommendations about *removing* the existing import lib support that
> libtool currently provides. I know, you probably don't think you did
> that -- but you said your new change would simplify libtool.
Chuck, thank you fo
USY;
+ if (check_valid_pointer (attr))
+return EINVAL;
*attr = new pthread_mutexattr ();
if (!pthread_mutexattr::isGoodObject (attr))
-----
2002-11-30 Ralf Habacker <[EMAIL PROTECTED]>
* thread.cc (__pthread
> > The only thing I like to say is, that instead of using a symbolic
> link to the
> > dll, the "unix" way may be possible.
> > What I mean is to put the dll into the lib dir (like the .so
> libraries in unix,
> > the bin dir contains only executables) and to implement a LD_LIBRARY_PATH
> > enviro
> -Original Message-
> From: Robert Collins [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 01, 2002 10:19 PM
> To: Ralf Habacker
> Cc: cygwin
> Subject: Re: problem with mutexattr initialisation
>
>
> On Sat, 2002-11-30 at 12:28, Ralf Habacker wrote:
>
> -Original Message-
> From: Jason Tishler [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 04, 2002 9:42 PM
> To: Ralf Habacker
> Cc: Cygwin
> Subject: Re: rebase-0.4 patch
>
>
> Ralf,
>
> On Wed, Dec 04, 2002 at 07:45:52AM +0100, Ralf Habacke
> > > 3. reformat via indent
> >
> > Which indent command line you will use. I can do it before, do simplifiy
> > applying backward to the kde-cygwin archive.
>
> Just 'indent'. However for C++, astyle --gnu does a better job of
> meeting the GNU standards, FWICT.
>
There are two possibilites.
>
> However for C++, astyle --gnu does a better job of
> meeting the GNU standards, FWICT.
>
$ astyle --gnu
Unknown command line option: gnu
For help on options, type 'astyle -h'
astyle --gnu does not work. It must be astyle --style=gnu.
What about spaces and tabs. Tabs would make big files small
> On Thu, Dec 05, 2002 at 08:44:37PM +1100, Robert Collins wrote:
> > On Thu, 2002-12-05 at 19:50, Ralf Habacker wrote:
> > > astyle --gnu does not work. It must be astyle --style=gnu.
> > >
> > > What about spaces and tabs. Tabs would make big files smaller as
> Please check out the latest snapshot and report here if there are
> problems. I haven't yet tried this on Windows 9x class systems so it's
> entirely possible that there is a problem there.
>
I've used this snapshot for running kde (Kmail,konqueror and other) a while on
windows 2000 and haven't
Hi all,
today I've found an interesting article about cygwin, cygwin/xfree and relating
topics in a german magazine.
See http://www.linux-magazin.de/Artikel/ausgabe/2002/12/cygwin/cygwin.html for
further informations.
Regards
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-sim
> hi folks, I am looking for a memory checker such as mpatrol running
> under cygwin
> Any one ever tried to run mpatrol under cygwin (or others)?
No, but perhaps "memwatch" library could help you.
See http://sourceforge.net/project/showfiles.php?group_id=27249
Ralf Hab
> 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 :-)
Ralf
--
Unsubscribe info:
> I *believe* (not reading German ;) that the same article
> is also in the English edition.
>
You're right. See http://www.linux-magazine.com/issue/26, but it seems that you
can find only the german story in the internet.
Ralf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
B
> > 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
> > 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
>>
> >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
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
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
> 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
> -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
>
> $
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
> >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
>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
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
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
> 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,
> 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
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
> 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
> 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
> 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
> 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
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
-
> 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
> 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
> 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
> >
> > > 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
>>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
>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
> > 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
> 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
> > 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
>
> > 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
>
> 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
> 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
> [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
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
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
> > 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
> 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
> 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
> 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
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 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.
$
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 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
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
1 - 100 of 224 matches
Mail list logo
