On 3/18/2017 9:52 AM, Daniel Santos wrote:
>
> Ok, thanks. I have a license for Windows 7 and while I know that Windows
> 10 is "free" I'm just not ready for that step. I will probably have to
> eventually setup a win10 vm though.
>
For me moving from Win7 to Win10 was no big deal other than th
On 03/17/2017 12:17 AM, Brian Inglis wrote:
On 2017-03-16 14:59, Daniel Santos wrote:
Alright, I think I've got it now, thank you. I'll experiment with it
first and then I'm guessing that this might eventually belong in
libtool or some such, although I'm guessing that that wouldn't work
unless
On 2017-03-16 14:59, Daniel Santos wrote:
> On 03/15/2017 02:36 PM, Brian Inglis wrote:
>> Do the local rebase on your build targets as detailed in my question
>> to Achim and his response. Rerun after any system change or build.
>
> Alright, I think I've got it now, thank you. I'll experiment wit
On 03/15/2017 02:36 PM, Brian Inglis wrote:
Do the local rebase on your build targets as detailed in my question
to Achim and his response. Rerun after any system change or build.
Alright, I think I've got it now, thank you. I'll experiment with it
first and then I'm guessing that this might
On 2017-03-15 10:54, Daniel Santos wrote:
> On 03/13/2017 12:25 PM, Marco Atzeri wrote:
>> The risk of collision is very low on 64 bit. It is higher on 32 bit
>> but as gcc don't depend on other libraries, I don't expect that to
>> happen.
I've seen "won't happen" take from 6 minutes to 6 months *
On 03/13/2017 12:25 PM, Marco Atzeri wrote:
The risk of collision is very low on 64 bit.
It is higher on 32 bit but as gcc don't depend on other libraries,
I don't expect that to happen.
If happens you can rebase in tree before running the tests,
providing the list of new dll to rebase.
I used i
On 13/03/2017 17:39, Daniel Santos wrote:
On 03/10/2017 12:56 PM, Achim Gratz wrote:
Brian Inglis writes:
Ensure that all Cygwin dlls including anything you build are included
in every rebase, and do an incremental rebase after every build.
Don't do this, it's not what incremental rebase is fo
On 03/10/2017 12:56 PM, Achim Gratz wrote:
Brian Inglis writes:
Ensure that all Cygwin dlls including anything you build are included
in every rebase, and do an incremental rebase after every build.
Don't do this, it's not what incremental rebase is for. I've
specifically implemented the "ephe
Thanks for the help Brian.
On 03/09/2017 05:51 PM, Brian Inglis wrote:
Windows DLLs updated or added could increase in size and overlap
Cygwin's assumed address space allocated by rebase.
Mingw has no problem as native Windows programs, but Cygwin emulates
how Unix uses shared libraries [handwav
Brian Inglis writes:
> Has that been released yet or is it implied in options -O --oblivious
> and -T --filelist=FILE as documented in NEWS?
Yes, -O is the option I was talking about (it now also implies -s, so
you don't need explicitly say that). The typical use would be with -T
as you say, may
On 2017-03-10 11:56, Achim Gratz wrote:
> Brian Inglis writes:
>> Ensure that all Cygwin dlls including anything you build are
>> included in every rebase, and do an incremental rebase after every
>> build.
> Don't do this, it's not what incremental rebase is for. I've
> specifically implemented
Brian Inglis writes:
> Ensure that all Cygwin dlls including anything you build are included
> in every rebase, and do an incremental rebase after every build.
Don't do this, it's not what incremental rebase is for. I've
specifically implemented the "ephemeral" option to rebase to temporarily
de
On 3/9/2017 6:51 PM, Brian Inglis wrote:
> On 2017-03-09 15:53, Daniel Santos wrote:
>
>>> If you are running a lot of Cygwin services, cron or Scheduled Tasks,
>>> and/or background processes, you may want to look at running cygserver
>>> to cache process info and common system info (including S
On 2017-03-09 15:53, Daniel Santos wrote:
> First of all, thank you for your response!
>
> On 03/08/2017 02:21 AM, Brian Inglis wrote:
>> After any Windows Update, or a lot of package installs, you may want
>> look at running
>> rebase-trigger full[rebase]
>> before rebooting to remove all Cyg
First of all, thank you for your response!
On 03/08/2017 02:21 AM, Brian Inglis wrote:
After any Windows Update, or a lot of package installs, you may want
look at running
rebase-trigger full[rebase]
before rebooting to remove all Cygwin and Windows processes, then
(with no Cygwin servic
On 2017-03-07 22:18, Daniel Santos wrote:
> On 03/07/2017 06:36 PM, David Billinghurst wrote:
>> On 8/03/2017 10:25, Daniel Santos wrote:
>>> My concern is with the dynamic portion of this behavior -- what
>>> is affected by environment variables.
>> Many years ago I ran a nightly build/test of gcc
On 03/07/2017 06:36 PM, David Billinghurst wrote:
On 8/03/2017 10:25, Daniel Santos wrote:
My concern is with the dynamic portion of this behavior -- what is
affected by environment variables.
Many years ago I ran a nightly build/test of gcc under cygwin and
reported the results to gcc-testr
On 8/03/2017 10:25, Daniel Santos wrote:
My concern is with the dynamic portion of this behavior -- what is
affected by environment variables.
Many years ago I ran a nightly build/test of gcc under cygwin and
reported the results to gcc-testresults. There may be is discussion on
the gcc mai
On 03/07/2017 07:58 AM, cyg Simple wrote:
On 3/6/2017 9:03 PM, Daniel Santos wrote:
On 03/05/2017 05:08 AM, David Billinghurst wrote:
No.
LD_LIBRARY_PATH is used by dlopen ().
PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us/lib
On 3/6/2017 9:03 PM, Daniel Santos wrote:
> On 03/05/2017 05:08 AM, David Billinghurst wrote:
>> No.
>>
>> LD_LIBRARY_PATH is used by dlopen ().
>>
>> PATH is one of the locations searched by Windows when starting
>> applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
>
> Than
On 03/05/2017 05:08 AM, David Billinghurst wrote:
No.
LD_LIBRARY_PATH is used by dlopen ().
PATH is one of the locations searched by Windows when starting
applications, see https://msdn.microsoft.com/en-us/library/7d83bc18.aspx
Thank you for this clarification. So load-time dlls are resolve
On 5/03/2017 18:36, Daniel Santos wrote:
Is this a documentation error then? (from
https://cygwin.com/cygwin-ug-net/setup-env.html)
The LD_LIBRARY_PATH environment variable is used by the Cygwin
function
dlopen () as a list of directories to search for .dll files to
load. This
en
Is this a documentation error then? (from
https://cygwin.com/cygwin-ug-net/setup-env.html)
The LD_LIBRARY_PATH environment variable is used by the Cygwin function
dlopen () as a list of directories to search for .dll files to
load. This
environment variable is converted from Windows
Seeing how this means that gcc testsuite results are useless for
exposing regressions in gcc libraries, I've opened a gcc bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79867
Daniel
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/fa
On 03/04/2017 09:46 PM, JonY wrote:
Cygwin does NOT use LD_LIBRARY_PATH, Cygwin uses PATH like all Windows
programs. It is one aspect that does not conform to *nix expectations.
Wonderful, this simplifies it greatly! I was wondering why the dlls
were under /usr/bin. :) Anyway, I'm waiting f
On 03/05/2017 02:52 AM, Daniel Santos wrote:
> Well, that's the silly thing; when I ran all of this on my patched code,
> I did not get these errors. I'm planning on re-running them kind-of in
> hopes that I *will* get these errors so that my compare will be clean,
> but to me this is still not g
HAH! Well I hadn't actually subscribed to the mailing list and decided
to check the archive to see if anybody replied only to the list. (I'm
subscribed now)
> In order to test gfortran 7.1 without installing, you will need to copy
> cyggfortran-4.dll into a folder which is on LD_LIBRARY_PATH. m
On 3/4/2017 12:48 AM, Daniel Santos wrote:
> Hello. I'm trying to validate a gcc patchset that affects msabi
> functions, so I need good test results on Cygwin, but my unpatched
> tests are getting hundreds of failures for which I cannot determine
> the cause. I'm running Cygwin 64 bit on Windows
Hello. I'm trying to validate a gcc patchset that affects msabi
functions, so I need good test results on Cygwin, but my unpatched tests
are getting hundreds of failures for which I cannot determine the cause.
I'm running Cygwin 64 bit on Windows 7 in a qemu vm (with kvm). My
sources are on a
29 matches
Mail list logo
