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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
>
>
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
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
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
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:
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
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
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.
27 matches
Mail list logo
