Chuck,
While reviewing the libtool-patches list I came across a discussion[1]
about compiler option support that gave me an idea.
The attached patch (against the latest 2.2.7a snapshot, not taking the
other patch into account) should allow libtool to accept the
-{shared,static}-libgcc flags
Excerpt from ./setup-1.7.exe --help:
-P --packages Specify packages to install
-l --local-package-dir Local package directory
I know from the faq that -l takes an argument of the package directory. This
should be expressed in the --help output. Something
w32api/winnls.h is lacking the macros for recognising UTF-16
surrogates: IS_HIGH_SURROGATE, IS_LOW_SURROGATE, IS_SURROGATE_PAIR.
Here's one way to define them, which avoids evaluating the characters
twice:
#define IS_HIGH_SURROGATE(c) (((c) & 0xFC00) == 0xD800)
#define IS_LOW_SURROGATE(c) (((c) &
On Aug 9 12:42, Andy Koppe wrote:
> w32api/winnls.h is lacking the macros for recognising UTF-16
> surrogates: IS_HIGH_SURROGATE, IS_LOW_SURROGATE, IS_SURROGATE_PAIR.
> Here's one way to define them, which avoids evaluating the characters
> twice:
>
> #define IS_HIGH_SURROGATE(c) (((c) & 0xFC00)
Ian Kelling wrote:
Excerpt from ./setup-1.7.exe --help:
-P --packages Specify packages to install
-l --local-package-dir Local package directory
I know from the faq that -l takes an argument of the package directory.
This should be expressed in the --hel
On Sun, Aug 09, 2009 at 02:50:48AM -0700, Ian Kelling wrote:
>Excerpt from ./setup-1.7.exe --help:
>-P --packages Specify packages to install
>-l --local-package-dir Local package directory
>
>I know from the faq that -l takes an argument of the package dire
Yaakov (Cygwin/X) wrote:
> The attached patch (against the latest 2.2.7a snapshot, not taking the
> other patch into account) should allow libtool to accept the
> -{shared,static}-libgcc flags and just pass them on to gcc.
It just can't be that simple, can it? Well, for *libgcc* I guess it can,
be
Charles Wilson wrote:
> Yaakov (Cygwin/X) wrote:
>> The attached patch (against the latest 2.2.7a snapshot, not taking the
>> other patch into account) should allow libtool to accept the
>> -{shared,static}-libgcc flags and just pass them on to gcc.
>
> It just can't be that simple, can it? Well,
Yaakov (Cygwin/X) wrote:
> On 28/07/2009 05:56, Dave Korn wrote:
>>Yeh, me too. I have a horrible hack in the distro gcc that ascends
>> directories until it finds ./lib/ and replaces that with /bin/
>
> I'm not sure how you did it, so I just made the attached patch to do
> just that.
After my XP laptop died I have gone to Vista. I installed cygwin on
vista, then did ash and
rebaseall, and now when I run cygwin, no matter what I do it says
"command not found". I
thought it was a permissions thing so (I think) I changed the
permissions by unclicking the
"Read only" button un
Hi - I'm having trouble setting up RXVT on WinXP.
I've got the following shortcut set up to launch RXVT:
C:\viper\cygwin\bin\rxvt.exe -sl 1500 -fn "Lucida Console-12" -bg black -fg
yellow -sr -e bash --rcfile "/cygdrive/c/viper/.bashrc"
My $HOME directory is set to the following, as seen in the
Looks like I fixed this. Seems if i take off the rcfile option and replace it
w/ a "--login" option, all's good.
Thanks
--- On Sun, 8/9/09, Paul Tomsic wrote:
> From: Paul Tomsic
> Subject: rxvt and path problems
> To: cygwin@cygwin.com
> Date: Sunday, August 9, 2009, 11:16 AM
> Hi - I'm ha
Charles Wilson wrote:
> This part is messy -- and unnecessary for the intended use case. In gcc,
> all you need to do is explicitly modify the Makefile.am's to pass the
> necessary option. You don't need to do anything to automake or
> libtoolize, AFAICT.
That's actually my /real/ plan for GCC,
On 09/08/2009 08:48, Charles Wilson wrote:
Your patch does basically what Dave's horrible hack did, except his also
works if you're installing somewhere other than under THE libdir. His
patch "walks" up the directory tree from the .la file location, until it
finds a great-uncle ../../../bin direc
On 09/08/2009 08:52, Charles Wilson wrote:
It just can't be that simple, can it? Well, for *libgcc* I guess it can,
because there is no libgcc.la. However, we also need similar
functionality for the other runtime libraries, but they DO have .la
files which throws a monkey wrench into the mix.
Yaakov (Cygwin/X) wrote:
> On 09/08/2009 08:48, Charles Wilson wrote:
>> Your patch does basically what Dave's horrible hack did, except his also
>> works if you're installing somewhere other than under THE libdir. His
>> patch "walks" up the directory tree from the .la file location, until it
>> f
On 09/08/2009 01:53, Yaakov (Cygwin/X) wrote:
I'm not sure how you did it, so I just made the attached patch to do
just that. It's a bit of a hack but I don't think it's so horrible.
Chuck, what do you think?
Oops, forgot something, try this patch instead.
Yaakov
2009-08-09 Yaakov Selkowitz
Yaakov (Cygwin/X) wrote:
> Oops, forgot something, try this patch instead.
One little thing:
> - *cygwin*,*lai,yes,no,*.dll | *mingw*,*lai,yes,no,*.dll |
> *cegcc*,*lai,yes,no,*.dll) tdlname=../bin/$dlname ;;
> + *cygwin*,*lai,yes,no,*.dll)
> + *mingw*,*lai,yes,no,*.d
Dave Korn wrote:
>> This part is messy -- and unnecessary for the intended use case. In gcc,
>> all you need to do is explicitly modify the Makefile.am's to pass the
>> necessary option. You don't need to do anything to automake or
>> libtoolize, AFAICT.
>
> That's actually my /real/ plan for GC
[ Replying to a fairly random post to revive this old thread. ]
Yaakov (Cygwin/X) wrote:
> Dave Korn wrote:
>> Ah, thanks for pointing this out. (The packages are of course broken as
>> far
>> as portability is concerned, as upstream GCC does not anywhere provide a 'cc'
>> executable; it's p
Yaakov (Cygwin/X) wrote:
> On 09/08/2009 08:52, Charles Wilson wrote:
>> It just can't be that simple, can it? Well, for *libgcc* I guess it can,
>> because there is no libgcc.la. However, we also need similar
>> functionality for the other runtime libraries, but they DO have .la
>> files which th
Charles Wilson wrote:
> OTOH, Dave, can you see any reason why Yaakov's simpler "hack" as
> modified by your 19:21:26UTC message shouldn't *ALSO* go in, along with
> --bindir support? It (1) seems like a reasonable approach, (2) doesn't
> suffer from the "hey that dir doesn't exist yet" problem,
Thank you for providing clisp version 2.48.
I am unable to start clisp if I specify the full linking set:
$ clisp -Kfull
/usr/lib/clisp-2.48/full/lisp.exe: error while loading shared libraries:
svm.dll: cannot open shared object file: No such file or directory
$ cygcheck -l clisp | grep svm.d
Hello,
is there meanwhile a solution for compiling real native
win32 binaries with gcc 4.3.x?
I mean something like the "-mno-cygwin" linker switch
within the gcc 3.x compiler collection/tools
Or how does a makefile looks like, if I want to compile
real native win32 executables with gcc >= 4.3.
On 09/08/2009 14:21, Dave Korn wrote:
Don't you suppose the MinGW guys would want this too?
Perhaps, but I'll leave that for them to decide.
Yaakov
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.
On 09/08/2009 15:19, Dave Korn wrote:
This makes me think that I should not ship anything by those names that is
merely an alias for gcc. It would help broken packages that assume the
existence of cc, but break any that assume the semantics of cc. I'm not sure
which of those two is best.
I
On 09/08/2009 15:26, Dave Korn wrote:
I don't think you needed to qualify that by saying "for gcc they may not be";
it applies to anything that uses autotools. As long as configure offers the
user --bindir, --libdir, and all these other options for freely renaming and
re-laying-out the $prefi
On 09/08/2009 13:19, Dave Korn wrote:
Ah, you won't have seen the recent thread. GCC and libffi are now synced
upstream. The version numbering is a red-herring; there were only ever minor
discrepancies between the two, it's not meant to be an API bump.
I had wondered about that; a diff of
Yaakov (Cygwin/X) wrote:
> The assumption that $bindir is $libdir/../bin has been there for some
> time; anyone using a nonconformant --bindir= is on their own anyway
> regardless of this patch.
The assumption is in libtool, not in autoconf, nor in configure, nor in the
Gnu Coding Standards, and
Yaakov (Cygwin/X) wrote:
> From a quick scan of the gcc patches list, it looks like they just
> synced the code between gcc and libffi. But, AFAICS from gcc SVN, they
> didn't add a libffi.pc pkg-config file, which the standalone version
> provides and some libffi-dependent packages expect to fin
On 09/08/2009 16:50, Dave Korn wrote:
The assumption is in libtool, not in autoconf, nor in configure, nor in the
Gnu Coding Standards, and it is an invalid assumption(*). It is *libtool* that
fails to conform, by assuming that $bindir will always and only ever have the
/default/ value that i
On 09/08/2009 17:04, Dave Korn wrote:
The current one isn't perfect, no, but is probably marginally better than
anything built from the pre-merge upstream libffi repository. Even after the
merge there were still a bunch of bugs, but I've fixed them in GCC and am just
waiting for one of the gu
Yaakov (Cygwin/X) wrote:
> On 09/08/2009 17:04, Dave Korn wrote:
> So let me put it to you this way: I have two packages requiring libffi,
> namely gnustep-base and pygobject2, the latter of which explicitly deps
> libffi-3.0. Which libffi should I use right now, gcc-4.3.2 or standalone?
Right
Paul Tomsic wrote:
Looks like I fixed this. Seems if i take off the rcfile option and
replace it w/ a "--login" option, all's good.
Thanks
--- On Sun, 8/9/09, Paul Tomsic wrote:
From: Paul Tomsic
Subject: rxvt and path problems
To: cygwin@cygwin.com
Date: Sunday, August 9, 2009, 11:16 AM
H
On 08/08/2009 11:29 PM, michael trott wrote:
I had already set Cron to run as my service from within Cygwin, and
also under services.msc Cron is running as me.
Are they the only two area's it need to me set?
You want to re-run 'cron-config' specifying that you want to run the
service as your u
On 08/09/2009 11:03 AM, DY wrote:
After my XP laptop died I have gone to Vista. I installed cygwin on
vista, then did ash and
rebaseall, and now when I run cygwin, no matter what I do it says
"command not found". I
thought it was a permissions thing so (I think) I changed the
permissions by uncl
On 08/09/2009 12:16 PM, Paul Tomsic wrote:
Hi - I'm having trouble setting up RXVT on WinXP. I've got the following
shortcut set up to launch RXVT:
C:\viper\cygwin\bin\rxvt.exe -sl 1500 -fn "Lucida Console-12" -bg black
-fg yellow -sr -e bash --rcfile "/cygdrive/c/viper/.bashrc"
My $HOME direc
On 08/09/2009 04:47 PM, Thomas Steinbach wrote:
Hello,
is there meanwhile a solution for compiling real native
win32 binaries with gcc 4.3.x?
I mean something like the "-mno-cygwin" linker switch
within the gcc 3.x compiler collection/tools
Or how does a makefile looks like, if I want to compi
38 matches
Mail list logo
