Re: Setup problem (2.889 32-bit)
On Tue, 6 Mar 2018 12:42:33, David Lee wrote: > I tried to perform a clean Cygwin installation and encountered a > problem with package versions. > > Steps > - > > 1. Download setup.exe. > 2. Run it. > 3. At "Cygwin Net Release Setup Program", click next. > 3. Choose "Install From Internet". Click next. > 4. Pick a root directory. Click next. > 5. Pick a local package directory. Click next. > 6. Pick a internet connection suitable for you (I had to choose "system > proxy"). >Click next. > 7. Pick a download site. Click next (I tried http://ftp.jaist.ac.jp > and http://mirrors.kernel.org). > 8. Let setup download setup.ini. > 9. On the "Select Packages" screen, pick bsdtar. Click next. (There is > nothing special about bsdtar; you can pick any packages that have > liblz4_1 as dependency; see below). > > 10. On the "Review and Confirm changes" screen, notice there are some > automatically pulled packages. One of them is "liblz4_1", at version > "131-1". However, the current version is "1.7.5-1". You can see by > going back to the previous screen and click on the "liblz4_1" package. > > Is there some reason that the setup program downloaded a previous > version instead the current one for liblz4_1? Thanks for helping. Bug in setup*. This also happens for x86_64. (maintainers are aware of this issue). As a reference, read https://cygwin.com/ml/cygwin/2018-03/msg00038.html (Btw, install v1.7.5-1) Henri -- 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
_FORTIFY_SOURCE has no effect for C++ due to usage of #define
Cygport now sets _FORTIFY_SOURCE=2 for C and C++ but this has no effect
for C++. In __SSP_FORTIFY_LEVEL is always set to 0 if
__cplusplus is defined. This is needed because ... use
#defines to replace the functions.
Testcase:
$ cat copy.c
#include
char sbuf[42], *dbuf;
void to_sbuf(const char *p)
{
strcpy(sbuf, p);
}
void to_dbuf(const char *p)
{
strcpy(dbuf, p);
}
Examine preprocessed code:
$ gcc -D_FORTIFY_SOURCE=2 -O2 -E copy.c > copy2.c
$ vim copy2.c # Remove unnecessary code && pretty-print
$ cat copy2.c
typedef unsigned int size_t;
char *__strcpy_chk(char *, const char *, size_t);
extern __inline__ __attribute__((__always_inline__, __gnu_inline__)) char *
__strcpy_ichk(char * restrict dst, const char * restrict src)
{
return __builtin___strcpy_chk(dst, src, __builtin_object_size(dst, 0));
}
char sbuf[42], *dbuf;
void to_sbuf(const char *p)
{
((__builtin_object_size(sbuf, 0) != (size_t)-1)
? __builtin___strcpy_chk(sbuf, p, __builtin_object_size(sbuf, 0))
: __strcpy_ichk(sbuf, p));
}
void to_dbuf(const char *p)
{
((__builtin_object_size(dbuf, 0) != (size_t)-1)
? __builtin___strcpy_chk(dbuf, p, __builtin_object_size(dbuf, 0))
: __strcpy_ichk(dbuf, p));
}
Why are these (a ? b : c) expanded from the "#define strcpy" needed?
Both branches lead to the same __builtin___strcpy_chk() call. Is this
possibly needed for (very) old compiler versions with weaker optimization?
According to "gcc -O2 -S" outputs, the generated code is identical for
this source:
$ cat copy3.c
typedef unsigned int size_t;
char *strcpy (char *restrict, const char *restrict);
char *__strcpy_chk(char *, const char *, size_t);
char sbuf[42], *dbuf;
void to_sbuf(const char *p)
{
__strcpy_chk(sbuf, p, 42);
}
void to_dbuf(const char *p)
{
strcpy(dbuf, p);
}
The same code is generated if strcpy() is replaced itself without a
"#define strcpy":
$ cat copy4.c
typedef unsigned int size_t;
char *strcpy (char *restrict, const char *restrict);
// #if __SSP_FORTIFY_LEVEL > 0
extern __inline__ __attribute__((__always_inline__, __gnu_inline__)) char *
strcpy(char * restrict dst, const char * restrict src)
{
return __builtin___strcpy_chk(dst, src, __builtin_object_size(dst, 0));
}
// #endif
char sbuf[42], *dbuf;
void to_sbuf(const char *p)
{
strcpy(sbuf, p); // changed to __strcpy_chk(sbuf, p, 42);
}
void to_dbuf(const char *p)
{
strcpy(dbuf, p); // unchanged
}
This variant would be also compatible with C++. Same results with CLang(++).
Christian
PS: There is an outdated "#define __restrict" section in
which checks for GCC version 2.95 only.
--
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
Setup-x86(_64) (v2.889) ... just a question
L.S., Just a question, meaning it may have been discussed in cygwin-apps, but I have been reading that list for quite a while now. Recently I reported a problem: https://cygwin.com/ml/cygwin/2018-03/msg00042.html (Another setup v2.889 regression? additional information) Jon T. applied a big hammer to solve the problem ... (in short, in the entry for cscope ,the version number in the "prev" subentry was replaced as follows: [prev] version: 15.8a-2 (i.e. version number 15.8.0.1-2 was replaced by a "version number" that is NOT part of the filename) Today David Lee reported a related problem: https://cygwin.com/ml/cygwin/2018-03/msg00083.html (Setup problem (2.889 32-bit) ) I replayed what David described and confirmed the issue. Then I downloaded and installed the most recent version of liblz4_1. When setup (install mode) is invoked again, it wants to install the previous version of liblz4_1 (of course!). ... so I applied Jon's big hammer to setup.ini and replaced 131-1 by 1.7.5-0 (version:) in the prev subentry (pkg liblz4_1) That removed the issue (again, of course!). However to my surprise /etc/setup/installed.db now lists: 64-@@ grep -e cscope -e lz4 /drv/e/Cygwin64-test/etc/setup/installed.db cscope cscope-15.8a-2.tar.bz2 1 < artifical version number liblz4_1 liblz4_1-1.7.5-0.tar.bz2 0 < ditto These files do NOT exist. The file names were "artificially crafted". The files that do exist, are: 64-@@ ls -l release/cscope release/lz4/liblz4_1 release/cscope: total 700 -rw-r--r-- 1 Henri None 381409 Mar 6 13:18 cscope-15.8.0.1-2.tar.bz2 -rw-r--r-- 1 Henri None 330264 Mar 6 13:16 cscope-15.8b-1.tar.xz release/lz4/liblz4_1: total 52 -rw-r--r-- 1 Henri None 30408 Mar 6 12:37 liblz4_1-1.7.5-1.tar.xz -rw-r--r-- 1 Henri None 17924 Mar 6 11:15 liblz4_1-131-1.tar.xz Is this the future of setup? Meaning, is it the intention that it may be possible that installed.db refers to files that do not exist? Henri -- 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: Setup-x86(_64) (v2.889) ... just a question (CORRECTION)
On 2018-03-06 14:39, Houder wrote: L.S., Just a question, meaning it may have been discussed in cygwin-apps, but I have been reading that list for quite a while now. [snip] I should have added: ... next I decided to install the previous versions of both cscope and liblz4_1. However to my surprise /etc/setup/installed.db now lists: 64-@@ grep -e cscope -e lz4 /drv/e/Cygwin64-test/etc/setup/installed.db cscope cscope-15.8a-2.tar.bz2 1 < artifical version number liblz4_1 liblz4_1-1.7.5-0.tar.bz2 0 < ditto These files do NOT exist. The file names were "artificially crafted". The files that do exist, are: 64-@@ ls -l release/cscope release/lz4/liblz4_1 release/cscope: total 700 -rw-r--r-- 1 Henri None 381409 Mar 6 13:18 cscope-15.8.0.1-2.tar.bz2 -rw-r--r-- 1 Henri None 330264 Mar 6 13:16 cscope-15.8b-1.tar.xz release/lz4/liblz4_1: total 52 -rw-r--r-- 1 Henri None 30408 Mar 6 12:37 liblz4_1-1.7.5-1.tar.xz -rw-r--r-- 1 Henri None 17924 Mar 6 11:15 liblz4_1-131-1.tar.xz Is this the future of setup? Meaning, is it the intention that it may be possible that installed.db refers to files that do not exist? Henri -- 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: sed seems to force UC filename on Mixed 8.3 filenames on FAT32
>> I looked for recent similar issues and only found https://superuser.com/questions/1297658/folder-names-become-uppercase-when-syncing-to-fat32-drive >> So if other users of this Win10 build start tripping on this same problem >> and reporting it, it may get looked at by MS. The site you mention also asked about variations in hardware or formatting mechanism. I find the identical behaviour in USB drives (local) and USB sticks (removable). In the past I have used Hitachi Microdrive to render Removable sticks Local, but can't find a version of this driver upgrade for 64-bit. (Not one that works, anyway. Several that don't.) Also identical behaviours whether the filesystem is formatted FAT32 in Windows or formatted FAT32 in Linux. So summarising: SOME (but not ALL) file transactions on FAT32 result in "Mixed case but no spaces 8.3" -> "ALL UPPER CASE 8.3" Examples are sed and dos2unix (and family); but not nano, or joe. I can't think of anything that I could reasonably test on a folder rather than a file to see the effect on foldername. Goodness knows how to upstream anything to MS. Finally, there was another Windows update yesterday, 05-MAR-2018: to version 1709 OS build 16299.251. Hopes of a return to correct behaviours were immediately dashed. :o( Fergus -- 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
Error
0 [main] bash 4564 find_fast_cwd : Warning: couldn't compute Fast_CWD pointer Please help -- 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: Setup-x86(_64) (v2.889) ... just a question
On 06/03/2018 13:39, Houder wrote: [...]> However to my surprise /etc/setup/installed.db now lists: 64-@@ grep -e cscope -e lz4 /drv/e/Cygwin64-test/etc/setup/installed.db cscope cscope-15.8a-2.tar.bz2 1 < artifical version number liblz4_1 liblz4_1-1.7.5-0.tar.bz2 0 < ditto These files do NOT exist. The file names were "artificially crafted". The files that do exist, are: 64-@@ ls -l release/cscope release/lz4/liblz4_1 release/cscope: total 700 -rw-r--r-- 1 Henri None 381409 Mar 6 13:18 cscope-15.8.0.1-2.tar.bz2 -rw-r--r-- 1 Henri None 330264 Mar 6 13:16 cscope-15.8b-1.tar.xz release/lz4/liblz4_1: total 52 -rw-r--r-- 1 Henri None 30408 Mar 6 12:37 liblz4_1-1.7.5-1.tar.xz -rw-r--r-- 1 Henri None 17924 Mar 6 11:15 liblz4_1-131-1.tar.xz Is this the future of setup? Meaning, is it the intention that it may be possible that installed.db refers to files that do not exist? Not only the future, but the present and past, as well. Despite appearances, these aren't filenames, but versions encoded in peculiar way, for backwards compatibility. See [1]. [1] https://cygwin.com/ml/cygwin/2018-02/msg00037.html -- 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: Setup-x86(_64) (v2.889) ... just a question
On 2018-03-06 16:38, Jon Turney wrote: On 06/03/2018 13:39, Houder wrote: [...]> However to my surprise /etc/setup/installed.db now lists: 64-@@ grep -e cscope -e lz4 /drv/e/Cygwin64-test/etc/setup/installed.db cscope cscope-15.8a-2.tar.bz2 1 < artifical version number liblz4_1 liblz4_1-1.7.5-0.tar.bz2 0 < ditto These files do NOT exist. The file names were "artificially crafted". The files that do exist, are: 64-@@ ls -l release/cscope release/lz4/liblz4_1 release/cscope: total 700 -rw-r--r-- 1 Henri None 381409 Mar 6 13:18 cscope-15.8.0.1-2.tar.bz2 -rw-r--r-- 1 Henri None 330264 Mar 6 13:16 cscope-15.8b-1.tar.xz release/lz4/liblz4_1: total 52 -rw-r--r-- 1 Henri None 30408 Mar 6 12:37 liblz4_1-1.7.5-1.tar.xz -rw-r--r-- 1 Henri None 17924 Mar 6 11:15 liblz4_1-131-1.tar.xz Is this the future of setup? Meaning, is it the intention that it may be possible that installed.db refers to files that do not exist? Not only the future, but the present and past, as well. Despite appearances, these aren't filenames, but versions encoded in peculiar way, for backwards compatibility. See [1]. [1] https://cygwin.com/ml/cygwin/2018-02/msg00037.html package_db.cc (package::flush() ): /* In INSTALLED.DB 3, lines are: 'packagename version flags', where version is encoded in a notional filename for backwards compatibility, and the only currently defined flag is user-picked (bit 0). */ Got it. Thank you. Made a note of this for myself. Henri -- 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: Error
On 06/03/2018 15:57, Sagar jack wrote: 0 [main] bash 4564 find_fast_cwd : Warning: couldn't compute Fast_CWD pointer Please help Sagar, that is a record in lack of info. Do you think we have a crystal ball ? For the warning please see: https://cygwin.com/faq.html#faq.using.fixing-find_fast_cwd-warnings and report the issue to whoever is distributing the software you are using. Regards Marco -- 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: sed seems to force UC filename on Mixed 8.3 filenames on FAT32
On 2018-03-06 07:01, Fergus Daly wrote: >>> I looked for recent similar issues and only found > https://superuser.com/questions/1297658/folder-names-become-uppercase-when-syncing-to-fat32-drive Have you checked that you get identical behaviour under cmd shell or PowerShell, and see the problem using dir? This would confirm that it is a file system problem and not the calls used. >>> So if other users of this Win10 build start tripping on this same >>> problem and reporting it, it may get looked at by MS. > > The site you mention also asked about variations in hardware or > formatting mechanism. I find the identical behaviour in USB drives > (local) and USB sticks (removable). In the past I have used Hitachi > Microdrive to render Removable sticks Local, but can't find a version > of this driver upgrade for 64-bit. (Not one that works, anyway. > Several that don't.) Also identical behaviours whether the filesystem > is formatted FAT32 in Windows or formatted FAT32 in Linux. > > So summarising: > > SOME (but not ALL) file transactions on FAT32 result in > > "Mixed case but no spaces 8.3" -> "ALL UPPER CASE 8.3" > > Examples are sed and dos2unix (and family); but not nano, or joe. I > can't think of anything that I could reasonably test on a folder > rather than a file to see the effect on foldername. > > Goodness knows how to upstream anything to MS. Settings/bottom of page/Make Windows better/Give us feedback > Finally, there was another Windows update yesterday, 05-MAR-2018: to > version 1709 OS build 16299.251. Hopes of a return to correct > behaviours were immediately dashed. :o( -- 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
Eclipse running on debian with remote display to cygwin X11 starts all squashed to a point
Here's what I do: - Start cygwin XLaunch for the Windows 10 desktop - Select "Multiple windows" - Launch the lxterminal locally - In an lxterminal tab do the command ssh -Y myhost.mydomain.lan - In the ssh session give the command ~/eclipse/java-oxygen/eclipse/eclipse What happens is that: 1. First the banner starts and displays normally 2. Then a window shows up squashed to a point, there is an eclipse icon (possibly intended for the toolbar) near the point, but it can't be selected 3. It's not possible to stretch or resize the point 4. I tried pressing the return to select the default in the workspace select dialog (which is the first dialog to open when eclipse is started normally) I think the problem is with cygwin X and/or the way I'm running it, because I have tried doing "ssh -Y " from a terminal window on the debian computer's mate desktop to a different computer, and then doing a new "ssh -Y" from the remote computer and back to the debian and then started eclipse on the debian computer. And that eclipse started normally, running through two ssh X forwards. Does anyone know what might be causing the eclipse display problem, and what I can do to fix it? Thanks! - Steinar -- 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
[ANNOUNCEMENT] Updated: qpdf-8.0.2-1
Versions 8.0.2-1 of qpdf libqpdf21 libqpdf-devel are available in the Cygwin distribution: CHANGES Latest upstream release DESCRIPTION QPDF is a command-line program that does structural, content-preserving transformations on PDF files. It also provides many useful capabilities to developers of PDF-producing software or for people who just want to look at the innards of a PDF file to learn more about how they work. QPDF is capable of creating linearized (also known as web-optimized) files and encrypted files. QPDF also supports a special mode designed to allow you to edit the content of PDF files in a text editor. QPDF includes support for merging and splitting PDFs through the ability to copy objects from one PDF file into another and to manipulate the list of pages in a PDF file. The QPDF library also makes it possible for you to create PDF files from scratch. HOMEPAGE http://qpdf.sourceforge.net/ Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) 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: Setup-x86(_64) (v2.889) ... just a question
Houder writes: > Is this the future of setup? Meaning, is it the intention that it may > be possible that installed.db refers to files that do not exist? The entries in that file have not been referring to actual file names for at least a decade if not longer. It's just been kept that way in order to stay compatible with any known and unknown consumers of that data. The only real meaning is the _version_ that setup knows to be installed (the packagename is the first part of the line and just repeated for the version part that still looks liek a filename). For setup itself, the file name to be installed doesn't need to match anything at all (it wouldn't even need a .tar.xz suffix to fihgure out the file type), but there's a naming convention that gets followed. It's mostly so that one can look at the install log and understand what has been installed or more easily find a file to manually install. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves -- 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: setup-x86_64.exe v2.889 doesn't select additionally downloaded packages when installing from local directory
On 03/03/2018 23:00, Robert Cohen wrote: Summary of problem: When installing Cygwin from a local directory, setup-x86_64.exe version 2.889 doesn't list the packages that I additionally selected for download when previously downloading to that directory, and the top line of the GUI under Category view says "No packages found<->Default". Continuing the install only installs the packages preselected by setup. Thanks for reporting this problem. Details: To install a fresh version of Cygwin, I usually do this: Run setup-x86_64.exe using "Download Without Installing", select some additional packages, and then after everything finished, I rerun setup-x86_64.exe using "Install from Local Directory", and then the GUI, under Category view, shows "All <-> Default", beneath which is a hierarchical list including the packages preselected by setup along with the additional ones that I selected when downloading. Here's the problem: I performed the above process using today's version of setup-x86_64.exe from cygwin.com, which according to setup.ini is setup version 2.889, and the "Download Without Installing" setup worked as expected. However, when I next did "Install from Local Directory" using that directory, instead of showing "All<->Default", it showed "No packages found<->Default", and only the packages preselected by setup were not going to be skipped. I tried changing "Default" to "Install" at the top level of the list, but that then selected everything for install, not just the preselected packages and the additional ones I had downloaded. I repeated this process using a few different mirror sites for the download phase, but that made no difference. Interestingly, if I copy an older version of setup-x86_64.exe into my already-downloaded directory, e.g. setup-x86_64.exe version 2.880, the GUI is able to find the selected packages that I had already downloaded using setup version 2.889, after of course giving a few warnings about the current ini file being from a newer version of setup. In other words, if I download using setup v2.889, then when subsequently installing from that directory, setup v2.889 doesn't know what additional packages I had selected, whereas setup v2.880 does know. I'm wondering if I'm not doing something correctly, or if there is an issue with version 2.889 of setup-x86_64.exe not finding packages that were additionally selected for download. I built an updated setup with some attempted fixes for these problems. https://cygwin.com/setup/setup-2.889-12-g1cf567.x86.exe https://cygwin.com/setup/setup-2.889-12-g1cf567.x86_64.exe Perhaps you could try that and see if it improves things for you? -- 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: setup-x86_64.exe v2.889 doesn't select additionally downloaded packages when installing from local directory
>From: Jon Turney >Sent: Tuesday, March 6, 2018 17:13 >To: The Cygwin Mailing List >Cc: Robert Cohen >Subject: Re: setup-x86_64.exe v2.889 doesn't select additionally downloaded >packages when installing from local directory > ... > >I built an updated setup with some attempted fixes for these problems. > >https://cygwin.com/setup/setup-2.889-12-g1cf567.x86.exe >https://cygwin.com/setup/setup-2.889-12-g1cf567.x86_64.exe > >Perhaps you could try that and see if it improves things for you? Hi, Jon, Thanks for the fixes. I tested setup-2.889-12-g1cf567.x86_64.exe, and after selecting category view on the installer and changing "Default" to "Install" at the top of the list, it appeared to select both the pre-selected and my own selected packages for installation, which if I recall correctly, is how it worked before this issue arose. I did get one postinstall script error: Package: _/libfontconfig-common fontconfig_dtd.sh exit code 2 Here's the related error from setup.log.full, along with info on the command that ran just before that one: 2018/03/06 17:57:14 running: C:\cygwin64\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash" Rebuilding info directory install-info: warning: no info dir entry in `/usr/share/info/latex2rtf.info.gz' 2018/03/06 17:57:31 running: C:\cygwin64\bin\bash.exe --norc --noprofile "/etc/postinstall/fontconfig_dtd.sh" could not open /etc/xml/catalog for saving add command failed 2018/03/06 17:57:31 abnormal exit: exit code=2 I looked in /etc/xml/, and the catalog file was there, containing the following: http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd";> Is the error from fontconfig_dtd.sh something to be concerned about? Regards, Robert -- 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: [ANNOUNCEMENT] fdk-aac 0.1.5-2
On Wed, 20 Dec 2017 18:07:15, Steven Penny wrote: its not a need - its a preference - i prefer static builds - the count of programs i regularly build is small, so the redundancy doesnt hurt my use case. also if I am to share my builds with others it makes for a smoother process - as you can end up with a single exe. notice carefully that many projects offer static and shared builds http://cygwin.com/ml/cygwin/2017-12/msg00240.html bumping this thread, as i discovered another package that does not have a static library. here is the current list: - mingw64-x86_64-expat - mingw64-x86_64-fdk-aac - mingw64-x86_64-gnutls - mingw64-x86_64-lua - mingw64-x86_64-nghttp2 - mingw64-x86_64-pcre and here is a list that do include static library: - mingw64-x86_64-curl - mingw64-x86_64-libgnurx - mingw64-x86_64-openssl - mingw64-x86_64-win-iconv - mingw64-x86_64-zlib -- 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
