Re: Fork issue on W10 WOW
Am 09.07.2018 um 14:37 schrieb Corinna Vinschen: It is like they put the 64bit System 32 over 0x6b00 (maybe) 0x6b00? In your previous mail you wrote 0x6f00. I used 0x6f00 for my last rebase experiment as wow64 was loading over there consistently. Anyway I found another craziness: Before I was using the system language default as DE, in that case the wow64 was loaded over 0x6f00. When I changed to system language default US and rebooted the wow64 was loaded over 0x7000. I am back again to system language default DE and now the wow64 is loaded at 51CD. The system 32 is still over 0x7000 It seems there is some type of ALSR for the wow64. I will try to rebase using 0x6b00 to see if make any change Regards Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cleanup disk space
Hello! I maybe am getting the message underway and I don't see the history on the message itself, and you seem to be replying somebody that posted a question before I joined the list. But I believe that if space is a concern there are two main points I can think of: - Selectively installing only packages you need. I do this myself, get rid of any x, gtk, kde, gnome related stuff - Using NTFS compression. You can do this by a per-folder level and compress just given folders (or files) "in-place" without making it unable to run/open the files. NTFS does this compression transparent to the user -- at the cost of additional CPU cycles to decompress the file when a read is attempted. To enable NTFS compression, you can do it for the whole disk. Open explorer, right-click disk, properties, and check the "compress this drive to save disk space" in the dialog that is displayed. You can do this for specific files/folders by right-clicking them, clicking 'properties', then 'advanced' and then checking the compression-specific checkbox that's displayed. This should go smoothly with cygwin... but nowadays I believe the space cygwin spends is negligible comparing to the size of the available disks... Zipping the files with bzip2/gzip/whatever may work for some editors that know to expand the files before opening, but that won't be the case in the majority of the applications. The transparent and native compression should be the best shot to shrink a big and cluttered cygwin installation in no time. Again, for the (potential) cost of performance. Hope this helps! On 7/10/2018 1:10 AM, b...@theworld.com wrote: I hesitate to jump in here but what about the common compression programs cygwin provides like bzip2 and xz? Maybe everyone knows about them and clearly you can't do this on files you actually need to use (e.g., executables, tho looking at /usr/bin some are 20MB each and if you know you don't actually run them ever...) And even an error can generally be undone with a simple uncompress command within reason. Don't compress the respective uncompress command! And zip and tar can be used to package up entire directories or wildcard matched files in one command. And if you find you really don't miss what you packed up they can be moved off disk entirely to a thumb drive or CD/DVD or whatever for more savings tho that's also true of the uncompressed versions but zip or tar archives are particularly handy for this. Maybe it's too obvious, apologies. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cleanup disk space (was: /lib/debug/usr/bin/cygwin1.dbg)
I hesitate to jump in here but what about the common compression programs cygwin provides like bzip2 and xz? Maybe everyone knows about them and clearly you can't do this on files you actually need to use (e.g., executables, tho looking at /usr/bin some are 20MB each and if you know you don't actually run them ever...) And even an error can generally be undone with a simple uncompress command within reason. Don't compress the respective uncompress command! And zip and tar can be used to package up entire directories or wildcard matched files in one command. And if you find you really don't miss what you packed up they can be moved off disk entirely to a thumb drive or CD/DVD or whatever for more savings tho that's also true of the uncompressed versions but zip or tar archives are particularly handy for this. Maybe it's too obvious, apologies. -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo* -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FPE in localtime.cc
On Jul 9 11:16, Brian Inglis wrote:
> On 2018-07-09 10:49, Corinna Vinschen wrote:
> > On Jul 9 15:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
> >> Hello,
> >>
> >> the following sample coredumps with FPE at localhost.cc:1962 with the
> >> latest snapshot (6/29/2018):
> ...
> > You can simplify your testcase by not calling any time functions:
> >
> > #define _GNU_SOURCE
> > #include
> > #include
> > #include
> >
> > #define SECSPERDAY 86400
> >
> > int main(int argc, char **argv)
> > {
> > feenableexcept(FE_ALL_EXCEPT);
> > long tdays = argc > 1 ? strtol (argv[1], NULL, 10) : 189;
> > long seconds = tdays * SECSPERDAY + 0.5;
> > printf ("%ld\n", seconds);
> > }
> >
> > This generates a SIGFPE on Linux as well.
> >
> > The line computing seconds is the same line as used by the localtime
> > function. Cygwin shares the entire localtime code with the various
> > BSDs, so I guess they would have the same problem.
> What is that line meant to do? Am I missing something?
> It should be the equivalent of (tdays*SECSPERDAY*2 + 1)/2!
> It converts an integer value to double, adds 1/2, and throws it away on
> conversion back, unless the intermediate has insufficient mantissa bits, in
> which case, it loses the low bits?
You may want to ask the original author why he used FP arithmetic in
this place. Maybe it's a way to avoid integer overflow. I'm reluctant
to change this given that this code is still used in BSD as well.
> > Bottom line is, don't bulk enable FP exceptions, but only if you really
> > need it for certain parts of your code. Don't expect library functions
> > to be SIGFPE clean under all circumstances.
>
> Maybe selectively enable specific FPEs to check for where needed.
> Or be careful what you wish for, as you just might get a lot more than you
> bargained for ;^>
That's what I meant.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: octave says WGL_ARB_multisample is missing
On 09/07/2018 02:22, William Mitchell wrote: Nope, same result. In fact, diff says there is no difference between this cygGL-1.dll and the one I downloaded a few days ago. I bought this computer in October 2012. It's due to be replaced anyway; certainly before the Windows 7 end-of-life a year and half from now, so I might as well replace it now and not worry about this problem any more. Ok. Thanks for testing, anyhow. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [PATCH setup] Sort the packages listed in the "confirm" dialog
On 07/06/2018 18:14, Ken Brown wrote: On 6/6/2018 4:44 PM, Jon Turney wrote: I know you had a few other patchsets in flight, which I've unfortunately taken my eye off. If it's easier, you could push a branch with somewhere with what's outstanding, and I'll see if I can pick them up. Here are the patchsets that I've sent in the last few months: Thanks very much for the summary. I think I'm more or less caught up now. I'd like to do another setup release soonish to get your useful fixes deployed, so please let me know if there's anything I've missed. 1. https://sourceware.org/ml/cygwin-apps/2018-03/msg00033.html > This still applies to the current HEAD. Applied 1/3, thanks. I've posted a suggestion for reworking 3/3. "Improve the handling of packagesource::sites" 2. https://sourceware.org/ml/cygwin-apps/2018-03/msg00051.html This also applies to the current HEAD. "setup: uninstalling an orphaned package" Applied, thanks. 3. https://sourceware.org/ml/cygwin-apps/2018-04/msg2.html This needs to be tweaked slightly. I'll send a v2 today or tomorrow. "Improve the handling of command line package selection" Applied, thanks. Next, there's the tentative proposal I made in https://sourceware.org/ml/cygwin-apps/2018-04/msg0.html, with a cygport patch that isn't quite right. That could use some followup eventually. Thanks. I think this shouldn't need any more setup changes to support. Finally, there's the older patchset attempting to distinguish between user URLs and Cygwin mirrors: https://sourceware.org/ml/cygwin-apps/2017-12/msg00051.html with a followup patchset here: https://sourceware.org/ml/cygwin-apps/2017-12/msg00066.html I'm honestly not sure whether this "user URL" idea is worth pursuing, because it might end up confusing users more than it helps them. But if you think it is, I'll push it to a branch for further work. Yeah, I tend to agree. We could be doing something better, but it's not very clear yet what that is :S
collecting information for versioned dependencies (was Re: setup -g ???)
On 02/04/2018 18:03, Ken Brown wrote: [Redirected to cygwin-apps from https://cygwin.com/ml/cygwin/2018-03/msg00365.html.] On 3/22/2018 6:46 PM, Jon Turney wrote: [...] This is basically correct. setup is now capable of being told about dependencies where upgrading an already installed package is required, but this information isn't currently collected (For example, some packages now exist (e.g. vim [1]), which were built with gcc 6.4.0-5 and cygport 0.31.0-1. These packages almost certainly use ssp/fortify functions in the cygwin DLL, and so require a cygwin package >=2.10.0-1 (technically, the requirement is cygwin API >=0.320), but the dependency recorded is only on the cygwin package at any version) (The example given is kind of incomplete, in that we could define an additional provides: to record that API version.) That's something someone could usefully work on, if they were so inclined. The attached cygport patch attempts to address this by requiring, for each dependency of a package, a version >= the version installed at the time the package was built. It treats only dependencies found by Thanks. This is an interesting approach to automatically collecting this information I hadn't considered. Problems are that (i) it makes package builds less reproducible (as these dependencies will depend on the currently installed version of them, which might well change over time), and (ii) it will tend of over-estimate the version required. I don't know how these problems are solved in other distros, but that's probably worth looking at... cygport, not those added via REQUIRES in the cygport file. My thinking is that the cygport user should be in control of added dependencies; s/he can add version numbers if desired. mksetupini would need to be updated to parse versioned dependencies. (Or maybe it's expecting a different syntax; I didn't check.)
[PATCH setup 1/2] Add Vendor() accessor method to SolvableVersion
---
libsolv.cc | 17 +
libsolv.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/libsolv.cc b/libsolv.cc
index 63942b2..955a1b2 100644
--- a/libsolv.cc
+++ b/libsolv.cc
@@ -209,6 +209,23 @@ SolvableVersion::sourcePackageName () const
return std::string(pool_id2str(pool, spkg));
}
+const std::string
+SolvableVersion::Vendor () const
+{
+ if (!id)
+return "";
+
+ // extract vendor
+ Solvable *solvable = pool_id2solvable(pool, id);
+ Id vendor = repo_lookup_id(solvable->repo, id, SOLVABLE_VENDOR);
+
+ // has no such attribute
+ if (!vendor)
+return "";
+
+ return std::string(pool_id2str(pool, vendor));
+}
+
SolvableVersion
SolvableVersion::sourcePackage () const
{
diff --git a/libsolv.h b/libsolv.h
index c218ab8..f394e65 100644
--- a/libsolv.h
+++ b/libsolv.h
@@ -73,6 +73,7 @@ class SolvableVersion
SolvableVersion sourcePackage () const;
// where this package archive can be obtained from
packagesource *source() const;
+ const std::string Vendor () const;
// fixup spkg_id
void fixup_spkg_id(SolvableVersion spkg_id) const;
--
2.17.0
[PATCH setup 2/2] Keep track of all known sites for a given version of a package
When adding a packageversion, extend it's packagesource::sites vector to
include the sites from any similar packageversions previously processed.
Also remove those packageversions from the libsolv pool so that libsolv will
always find the one that lists all the sites.
This is needed for:
- Correct handling of local installs where required packages are spread
between cache directories for more than one mirror
- Correctly falling back to a second site when multiple mirrors are used and
a problem occurs connecting to the first mirror tried.
---
package_db.cc | 14 +++--
package_meta.cc | 80 ++---
package_meta.h | 2 +-
3 files changed, 67 insertions(+), 29 deletions(-)
diff --git a/package_db.cc b/package_db.cc
index 945b339..b74aafd 100644
--- a/package_db.cc
+++ b/package_db.cc
@@ -245,11 +245,8 @@ packagedb::addBinary (const std::string ,
packages.insert (packagedb::packagecollection::value_type(pkgname, pkg));
}
- /* Create the SolvableVersion */
- SolvableVersion sv = solver.addPackage(pkgname, pkgdata);
-
- /* Register it in packagemeta */
- pkg->add_version (sv, pkgdata);
+ /* Create the SolvableVersion and register it in packagemeta */
+ pkg->add_version (pkgdata);
return pkg;
}
@@ -266,11 +263,8 @@ packagedb::addSource (const std::string ,
sourcePackages.insert (packagedb::packagecollection::value_type(pkgname,
pkg));
}
- /* Create the SolvableVersion */
- SolvableVersion sv = solver.addPackage(pkgname, pkgdata);
-
- /* Register it in packagemeta */
- pkg->add_version (sv, pkgdata);
+ /* Create the SolvableVersion and register it in packagemeta */
+ SolvableVersion sv = pkg->add_version (pkgdata);
return sv;
}
diff --git a/package_meta.cc b/package_meta.cc
index a651d28..f765baf 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -123,11 +123,26 @@ packagemeta::~packagemeta()
versions.clear ();
}
-void
-packagemeta::add_version (packageversion & thepkg, const
SolverPool::addPackageData )
+SolvableVersion
+packagemeta::add_version (const SolverPool::addPackageData )
{
+ SolverPool::addPackageData pkgdata = inpkgdata;
+
+ packageversion *v = NULL;
+ switch (pkgdata.stability)
+{
+case TRUST_CURR:
+ v = &(this->curr);
+ break;
+case TRUST_TEST:
+ v = &(this->exp);
+ break;
+default:
+ break;
+}
+
/*
-If a packageversion for the same version number is already present,allow
+If a packageversion for the same version number is already present, allow
this version to replace it.
There is a problem where multiple repos provide a package. It's never been
@@ -137,12 +152,52 @@ packagemeta::add_version (packageversion & thepkg, const
SolverPool::addPackageD
We rely on this by adding packages from installed.db last.
*/
- set ::iterator i = versions.find(thepkg);
- if (i != versions.end())
+ for (set ::iterator i = versions.begin();
+ i != versions.end();
+ i++)
{
+ if (i->Canonical_version() != pkgdata.version)
+continue;
+
+ if (pkgdata.vendor == i->Vendor())
+{
+ /* Merge the site-list from any existing packageversion with the same
+ repository 'release:' label */
+ pkgdata.archive.sites.insert(pkgdata.archive.sites.end(),
+ i->source()->sites.begin(),
+ i->source()->sites.end());
+
+ /* Installed packages do not supersede repo packages */
+ if (pkgdata.reponame != "_installed")
+{
+ /* Ensure a stability level doesn't point to a version we're
about
+ to remove */
+ if (v && (*v == *i))
+*v = packageversion();
+
+ i->remove();
+}
+}
+ else
+{
+ /* Otherwise... if we had a way to set repo priorities, that could be
+ used to control which packageversion the solver picks. For the
+ moment, just warn that you might not be getting what you think you
+ should... */
+ Log (LOG_PLAIN) << "Version " << pkgdata.version << " of package " <<
+name << " is present in releases labelled " << pkgdata.vendor <<
+" and " << i->Vendor() << endLog;
+}
+
versions.erase(i);
+
+ break;
}
+ /* Create the SolvableVersion */
+ packagedb db;
+ SolvableVersion thepkg = db.solver.addPackage(name, pkgdata);
+
/* Add the version */
std::pair::iterator, bool> result =
versions.insert (thepkg);
@@ -154,19 +209,6 @@ packagemeta::add_version (packageversion & thepkg, const
SolverPool::addPackageD
#endif
/* Record the highest version at a given stability level */
- packageversion *v = NULL;
- switch (pkgdata.stability)
-{
-case TRUST_CURR:
- v = &(this->curr);
- break;
-case TRUST_TEST:
- v = &(this->exp);
-
Re: [PATCH setup 3/3] Keep track of all known sites for a given version of a package
On 17/03/2018 14:59, Ken Brown wrote:
When adding a packageversion for an entry in setup.ini, make its
packagesource::sites vector include the sites from previously
processed ini files.
Also remove from the libsolv pool the previous packageversions, so
that libsolv will always find the one that lists all the sites.
Thanks.
I think that this might be better done in packagemeta::add_version() as
you originally proposed, although that does involve moving more things
around.
A couple of patches which replace this one to do that follow.
diff --git a/package_meta.cc b/package_meta.cc
index 7f8110d..89b67bc 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -140,6 +140,14 @@ packagemeta::add_version (packageversion & thepkg, const
SolverPool::addPackageD
set ::iterator i = versions.find(thepkg);
if (i != versions.end())
{
+ if (pkgdata.reponame != "_installed")
+ {
+ if (curr == *i)
+ curr = thepkg;
+ if (exp == *i)
+ exp = thepkg;
+ i->remove();
+ }
A comment would have been useful here. It took a bit of head scratching
and testing with this removed to understand what this part is doing.
Re: octave says WGL_ARB_multisample is missing
I misunderstood you initially.
Hey, that works! Not quite as pretty, but I can work with it.
Thanks to all.
On 9 July 2018 at 01:18, Marco Atzeri wrote:
> Am 7/9/2018 um 2:55 AM schrieb William Mitchell:
>
>> Yes, I use gnuplot and xmgrace in other situations. But here I have
>> several .m programs which will need octave (or Matlab).
>>
>>
> I understood, but I am talking of octave graphics interface
>
> See also
> https://octave.org/doc/v4.4.0/Graphics-Toolkits.html
>
> have you tried to plot with another graphics interface ?
>>> What is the output of
>>>
>>
> this is an octave command
>
>available_graphics_toolkits
>>>
>>
> and its output should be like
>
> octave:1> available_graphics_toolkits
> ans =
> {
> [1,1] = fltk
> [1,2] = gnuplot
> }
>
> The default toolkit can be changed
>
> octave:1> graphics_toolkit()
> ans = fltk
> octave:2> graphics_toolkit("gnuplot")
> octave:3> graphics_toolkit()
> ans = gnuplot
>
>
>
>>> Usually the "gnuplot" is the less demanding one.
>>>
>>> Regards
> Marco
>
>
> ---
> Diese E-Mail wurde von AVG auf Viren geprüft.
> http://www.avg.com
>
>
> --
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
>
>
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: FPE in localtime.cc
On 2018-07-09 10:49, Corinna Vinschen wrote:
> On Jul 9 15:47, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
>> Hello,
>>
>> the following sample coredumps with FPE at localhost.cc:1962 with the latest
>> snapshot (6/29/2018):
...
> You can simplify your testcase by not calling any time functions:
>
> #define _GNU_SOURCE
> #include
> #include
> #include
>
> #define SECSPERDAY 86400
>
> int main(int argc, char **argv)
> {
> feenableexcept(FE_ALL_EXCEPT);
> long tdays = argc > 1 ? strtol (argv[1], NULL, 10) : 189;
> long seconds = tdays * SECSPERDAY + 0.5;
> printf ("%ld\n", seconds);
> }
>
> This generates a SIGFPE on Linux as well.
>
> The line computing seconds is the same line as used by the localtime
> function. Cygwin shares the entire localtime code with the various
> BSDs, so I guess they would have the same problem.
What is that line meant to do? Am I missing something?
It should be the equivalent of (tdays*SECSPERDAY*2 + 1)/2!
It converts an integer value to double, adds 1/2, and throws it away on
conversion back, unless the intermediate has insufficient mantissa bits, in
which case, it loses the low bits?
> Bottom line is, don't bulk enable FP exceptions, but only if you really
> need it for certain parts of your code. Don't expect library functions
> to be SIGFPE clean under all circumstances.
Maybe selectively enable specific FPEs to check for where needed.
Or be careful what you wish for, as you just might get a lot more than you
bargained for ;^>
--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
FPE in localtime.cc
Hello,
the following sample coredumps with FPE at localhost.cc:1962 with the latest
snapshot (6/29/2018):
#define _GNU_SOURCE
#include
#include
#include
static time_t s_Time;
static void fun(void)
{
char buf[40];
strftime(buf, sizeof(buf), "%m/%d/%y %H:%M:%S", localtime(_Time));
printf("%s\n", buf);
}
int main()
{
feenableexcept(FE_ALL_EXCEPT);
time(_Time);
fun();
}
$ cat a.exe.stackdump
Exception: STATUS_FLOAT_INEXACT_RESULT at rip=001800BBA24
rax=016D rbx=5B43498E rcx=01EC
rdx=1845C8A0CE512957 rsi=51EB851F rdi=2CC3D8D4A245F203
r8 =00F92B80 r9 =FFED r10=07E2
r11=000C r12= r13=8000
r14=00BD r15=07E2
rbp=7FFF rsp=CA70
program=C:\Cygwin64\...\a.exe, pid 14232, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Removing the first line of the main() function lets the program run
successfully.
The same code runs fine unmodified on Linux.
$ gcc -Wall sample.c -lm
$ ./a.out
07/09/18 11:44:26
Any ideas?
Thanks,
Anton Lavrentiev
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Ruby returning invalid entry sizes
On Jul 9 09:25, cyg Simple wrote:
> On 7/9/2018 5:10 AM, Corinna Vinschen wrote:
> > On Jul 8 20:34, Steven Penny wrote:
> >> If you run this command with Linux Ruby or RubyInstaller [1]:
> >>
> >>$ ruby -e 'p File.size(".")'
> >>65536
> >>
> >> you correctly get the IO Blocks for the current directory. However not with
> >> Cygwin Ruby:
> >>
> >>$ ruby -e 'p File.size(".")'
> >>0
> >
> > https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=07c43238cfec
> >
>
> Corinna, you typoed the word "always" in the Changelog.
>
> + * fhandler_disk_file.cc (fhandler_base::fstat_helper): Alwasy set
Yes? The ChangeLog is from 2011. What's your point?
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Ruby returning invalid entry sizes
On 7/9/2018 5:10 AM, Corinna Vinschen wrote:
> On Jul 8 20:34, Steven Penny wrote:
>> If you run this command with Linux Ruby or RubyInstaller [1]:
>>
>>$ ruby -e 'p File.size(".")'
>>65536
>>
>> you correctly get the IO Blocks for the current directory. However not with
>> Cygwin Ruby:
>>
>>$ ruby -e 'p File.size(".")'
>>0
>
> https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=07c43238cfec
>
Corinna, you typoed the word "always" in the Changelog.
+ * fhandler_disk_file.cc (fhandler_base::fstat_helper): Alwasy set
--
cyg Simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Fork issue on W10 WOW
On Jul 9 13:37, Marco Atzeri wrote: > Am 7/9/2018 um 11:03 AM schrieb Corinna Vinschen: > > On Jul 8 18:03, Marco Atzeri wrote: > > > Am 30.06.2018 um 22:47 schrieb Ken Brown: > > > > On 6/30/2018 11:52 AM, Marco Atzeri wrote: > > > > > > > > I've never had this problem with my own 32bit installation on W10, but I > > > > just reproduced it by doing a new installation with your list of > > > > packages. Have you tried just installing a minimal list of packages > > > > that you need for building the packages you maintain? > > > > > > > > > > On a fresh minimal installation the problem can arise again > > > > > > $ cygcheck -cd |wc -l > > > 245 > > > > > > as the first system shared libs are lower than the rebase > > > DefaultBaseAddress=0x07000 > > > > > > 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll > > > 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll > > > > > > I think that rebase should consider different rebase > > > base address for W10. > > > > > > Using DefaultBaseAddress=0x06F00 seems fine > > > for the time being > > > > I can do that in the rebaseall script (I have a matching patch locally), > > but it looks like a race we can't win in the long run. 240 Megs less > > space is a lot given the number of DLLs in the distro. > > I know, but until we try to support the 32bit version, we need a > way to handle it. > > > To make matters worse, I just checked my local 32 bit W10 and it turns > > out that various Windows DLLs loaded by default (even in a simple tcsh) > > are at even lower addresses, e.g. > > > >6B69-6B6A3000 /mnt/c/Windows/System32/netapi32.dll > > I suspect it is due the their 64bit base address netapi32.dll is 32 bit. And it's a 32 bit OS, not WOW64... > $ objdump -x /cygdrive/c/Windows/System32/wow64.dll|grep ImageBase > ImageBase 6b00 > > $ objdump -x /cygdrive/c/Windows/System32/wow64win.dll |grep ImageBase > ImageBase 6b18 > > It is like they put the 64bit System 32 over 0x6b00 (maybe) 0x6b00? In your previous mail you wrote 0x6f00. > and the WoW64 over 0x7000 I don't think there's a rule. On my 64 bit W10 system: 76E6-76ED8000 /mnt/c/Windows/System32/wow64win.dll 76EE-76EEA000 /mnt/c/Windows/System32/wow64cpu.dll 76EF-76F42000 /mnt/c/Windows/System32/wow64.dll Of course you can rebase the wow64 DLLs, it's just unclear if that helps, given Windows uses different DLL addresses for their system DLLs after each reboot. > But I guess that ALSR can play around that numbers. > There is still a way to disable ALSR? ASLR is disabled by default on Cygwin executables. Unless it can't be disabled anymore for certain (system?) DLLs. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: RFC: setup package in Base
On 7/7/2018 8:40 AM, Jon Turney wrote: On 06/07/2018 15:05, Jon Turney wrote: On 06/07/2018 14:51, Jon Turney wrote: Thanks for the patch. The version is checked (again), at ini.cc:404 I've never understood why we have this twice. (I think the idea might be that first we are checking the setup version as a proxy for the setup.ini format version, to warn if there might be problems parsing it. The second time we are checking the setup version to see if an upgrade of setup is possible) Ah, so now we have setup-minimum-version, checking setup-version: in the ini parser should probably be removed (or disabled when setup-minimum-version: is present?) Like so: Yes, this is better than my attempt. I hadn't noticed that setup-version: was checked again in ini.cc. Ken
Re: Fork issue on W10 WOW
Am 7/9/2018 um 11:03 AM schrieb Corinna Vinschen: On Jul 8 18:03, Marco Atzeri wrote: Am 30.06.2018 um 22:47 schrieb Ken Brown: On 6/30/2018 11:52 AM, Marco Atzeri wrote: I've never had this problem with my own 32bit installation on W10, but I just reproduced it by doing a new installation with your list of packages. Have you tried just installing a minimal list of packages that you need for building the packages you maintain? On a fresh minimal installation the problem can arise again $ cygcheck -cd |wc -l 245 as the first system shared libs are lower than the rebase DefaultBaseAddress=0x07000 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll I think that rebase should consider different rebase base address for W10. Using DefaultBaseAddress=0x06F00 seems fine for the time being I can do that in the rebaseall script (I have a matching patch locally), but it looks like a race we can't win in the long run. 240 Megs less space is a lot given the number of DLLs in the distro. I know, but until we try to support the 32bit version, we need a way to handle it. To make matters worse, I just checked my local 32 bit W10 and it turns out that various Windows DLLs loaded by default (even in a simple tcsh) are at even lower addresses, e.g. 6B69-6B6A3000 /mnt/c/Windows/System32/netapi32.dll I suspect it is due the their 64bit base address $ objdump -x /cygdrive/c/Windows/System32/wow64.dll|grep ImageBase ImageBase 6b00 $ objdump -x /cygdrive/c/Windows/System32/wow64win.dll |grep ImageBase ImageBase 6b18 It is like they put the 64bit System 32 over 0x6b00 (maybe) and the WoW64 over 0x7000 But I guess that ALSR can play around that numbers. There is still a way to disable ALSR? Corinna Marco --- Diese E-Mail wurde von AVG auf Viren geprüft. http://www.avg.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Ruby returning invalid entry sizes
On Jul 8 20:34, Steven Penny wrote:
> If you run this command with Linux Ruby or RubyInstaller [1]:
>
>$ ruby -e 'p File.size(".")'
>65536
>
> you correctly get the IO Blocks for the current directory. However not with
> Cygwin Ruby:
>
>$ ruby -e 'p File.size(".")'
>0
https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=07c43238cfec
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Fork issue on W10 WOW
On Jul 8 18:03, Marco Atzeri wrote: > Am 30.06.2018 um 22:47 schrieb Ken Brown: > > On 6/30/2018 11:52 AM, Marco Atzeri wrote: > > > > I've never had this problem with my own 32bit installation on W10, but I > > just reproduced it by doing a new installation with your list of > > packages. Have you tried just installing a minimal list of packages > > that you need for building the packages you maintain? > > > > On a fresh minimal installation the problem can arise again > > $ cygcheck -cd |wc -l > 245 > > as the first system shared libs are lower than the rebase > DefaultBaseAddress=0x07000 > > 6F81-6F811000 r--p /cygdrive/c/Windows/System32/wow64.dll > 6F811000-6F844000 r-xp /cygdrive/c/Windows/System32/wow64.dll > > I think that rebase should consider different rebase > base address for W10. > > Using DefaultBaseAddress=0x06F00 seems fine > for the time being I can do that in the rebaseall script (I have a matching patch locally), but it looks like a race we can't win in the long run. 240 Megs less space is a lot given the number of DLLs in the distro. To make matters worse, I just checked my local 32 bit W10 and it turns out that various Windows DLLs loaded by default (even in a simple tcsh) are at even lower addresses, e.g. 6B69-6B6A3000 /mnt/c/Windows/System32/netapi32.dll Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: running self compiled 32 bit binary on 64 bit Windows?
On Mon 2018-07-09 (05:18), Andrey Repin wrote: > > SIGH. I was hoping a 32 bit cygwin with 32 bit self compiled programs will > > run on 64 bit Windows, too. But I was wrong. > > Meanwhile I have 4 VMs: > > Windows 32 bit with 32 bit cygwin > > Windows 32 bit with 32 bit cygwin for compiling > > Windows 64 bit with 64 bit cygwin > > Windows 64 bit with 64 bit cygwin for compiling > > You can install both 32 and 64-bit Cygwin on the same machine. > So you don't really need 4, while I see how having a build system separate is > a good idea. But I also need a test VM to check whether my self compiled programs will run on an other system. > > I have several 100 users, none of them is able to install cygwin > > *You* have to do it. No, I cannot do that. I do not have access to their PCs. > > I give them my preconfigured cygwin.zip (or cygwin64.zip) and tell them to > > unpack it in C:\ > > > http://fex.belwue.de/usecases/cygwin.html > > > This works so far without problems. > > Only by accident and promise. This is sufficent for me :-) -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlac...@tik.uni-stuttgart.de Allmandring 30aTel:++49-711-68565868 70569 Stuttgart (Germany) WWW:http://www.tik.uni-stuttgart.de/ REF:<1124060518.20180709051...@yandex.ru> -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: running self compiled 32 bit binary on 64 bit Windows?
On 2018-07-08 20:18, Andrey Repin wrote: >> On Fri 2018-06-08 (19:41), Andrey Repin wrote: > 2.) Do a Cygwin build and copy cygwin1.dll I already have a /usr/bin/cygwin1.dll on the Windows 8 target system. >>> It's a wrong architecture. You need a 32-bit one for your 32-bit program. Do I have to replace it? >>> No. >>> Just build a 64-bit version of your program. >> SIGH. I was hoping a 32 bit cygwin with 32 bit self compiled programs will >> run on 64 bit Windows, too. But I was wrong. He just means that you must provide matching Cygwin DLLs and exes which are either all built as x86 (32 bit), or all as x86_64. Cygwin x86 programs will run on Windows x64 or x86 desktops as they support x86 programs. >From Windows Server 2008 R2, all *servers* are x64 only, and x86 support is an optional installable feature on *servers*, except it is still required for AD support, which MS has still not rewritten for x64. >> Meanwhile I have 4 VMs: >> Windows 32 bit with 32 bit cygwin >> Windows 32 bit with 32 bit cygwin for compiling >> Windows 64 bit with 64 bit cygwin >> Windows 64 bit with 64 bit cygwin for compiling > You can install both 32 and 64-bit Cygwin on the same machine. > So you don't really need 4, while I see how having a build system separate is > a good idea. This is what I first did: Transfered the 32 bit cygwin with my self compiled binaries >>> You have to install Cygwin, not "transfer". >> I have several 100 users, none of them is able to install cygwin > *You* have to do it. > Cygwin offers tools to automate process. More explanation would be helpful. He could setup a package download structure, including setup-x86[_64].exe and setup.ini, zip that for transfer, unzip that in a known location, then run the included setup in unattended mode with fixed arguments, to setup the Cygwin environment, install the base and other packages. Have you other suggestions? >> and the packages they need the official way, they are way to *CENSORED* for >> this job :-} >> I give them my preconfigured cygwin.zip (or cygwin64.zip) and tell them to >> unpack it in C:\ >> http://fex.belwue.de/usecases/cygwin.html >> (This is what I call "transfer cygwin") >> This works so far without problems. > Only by accident and promise. More explanation would be helpful. What problems do you see with his process? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
