Re: i686 ld couldn't resolve wglCreateContext from libopengl32.a on x86_64 system
On Thu, Mar 2, 2017 at 5:19 PM, Yaakov Selkowitz wrote: > > Maybe, maybe not. Mixing *NIX and Win32 APIs isn't so simple. > I have some small projects that do this mixing. A determined individual can do it. I have not done it with 'wgl' -- 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: i686 ld couldn't resolve wglCreateContext from libopengl32.a on x86_64 system
On 2017-03-02 18:14, sorryforaskingthis.bk.ru via cygwin wrote: On 2017-03-02 16:54, Yaakov Selkowitz wrote: This looks like a snippet of an autoconf AC_CHECK_LIB (or AC_CHECK_FUNCTION) test. Such tests don't work with 32-bit Win32 APIs -- on either Cygwin or MinGW -- because they don't take stdcall into account. You'll need to modify the test to work around that. Also, if you're using Cygwin, do you *really* want to be using Win32 OpenGL and not X11? Yes, you're right. It's autoconf test and it perfectly passed at 64-bit MinGW and 64-bit Cygwin, but not on 32-bit Cygwin. It would fail on 32-bit MinGW too. And I don't understand why you're say that it is related to stdcall, while wglCreateContext exposed directly without any @0 @4 etc. No, it's not, check the implib yourself. You have to use a proper declaration to link stdcall functions, and the autoconf tests don't do that. You need to change the test to avoid this; exactly how depends on the intent of the test. Yes, I need to use Win32. I want to port application that heavily POSIX-dependent, but also want to save performance as much as possible. Big difference. I think if w32api-runtime package is provided it supposed to work. Maybe, maybe not. Mixing *NIX and Win32 APIs isn't so simple. -- Yaakov -- 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: i686 ld couldn't resolve wglCreateContext from libopengl32.a on x86_64 system
>On 2017-03-02 16:54, Yaakov Selkowitz wrote: > >This looks like a snippet of an autoconf AC_CHECK_LIB (or >AC_CHECK_FUNCTION) test. Such tests don't work with 32-bit Win32 APIs >-- on either Cygwin or MinGW -- because they don't take stdcall into >account. You'll need to modify the test to work around that. > >Also, if you're using Cygwin, do you *really* want to be using Win32 >OpenGL and not X11? > Yes, you're right. It's autoconf test and it perfectly passed at 64-bit MinGW and 64-bit Cygwin, but not on 32-bit Cygwin. And I don't understand why you're say that it is related to stdcall, while wglCreateContext exposed directly without any @0 @4 etc. With --enable-stdcall-fixup ld says: undefined reference to `wglCreateContext@0' Yes, I need to use Win32. I want to port application that heavily POSIX-dependent, but also want to save performance as much as possible. I think if w32api-runtime package is provided it supposed to work.
Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
On 2017-03-02 11:45, Eric Blake wrote:
> On 03/02/2017 11:28 AM, Brian Inglis wrote:
>> summary of checkbashisms -f run on 140 POSIX shell scripts as
>> identified by file in my Cygwin 64 /bin/ with 784 packages (about
>> 20% of cygwin-pkg-maint, 8% of setup.ini) installed, 70 possible
>> issues (some from wrapped scripts because of -f):
>
> Looking through some of the output, I already spot a few interesting
> things:
>
>> possible bashism in /bin/autoconf-2.69 line 55 ($BASH_SOMETHING):
>> if test -z "$BASH_VERSION$ZSH_VERSION" \
>> && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
>
> Not a problem - the script is probing whether it needs to do
> something based on being bash or not, but is written with all shells
> in mind.
>
>> error: /bin/autoconf-2.69: Unterminated quoted string found, EOF
>> reached. Wanted: <'>, opened in line 429
>
> bug in checkbashisms; looks like it happens in several places in the
> output
Because of -f checks shell wrappers which it would otherwise just ignore
- may not be helpful - but -px (POSIX + eXtra) may be more useful, as
checkbashisms defaults to lintian checks where Debian Policy 10.4
overrides POSIX.
Also running with -f on bash scripts and checking for exit 4 identifies
candidates for changing shebang from bash to sh.
>> possible bashism in /bin/autopoint line 57 ($RANDOM):
>> tmp=$TMPDIR/gt$$-$RANDOM
> Not a problem - the script is using $RANDOM for an additional level
> of safety, but works safely even when $RANDOM is the empty string (as
> on dash).
Those are where I suggested mktemp would be a better solution to provide
a random string - most scripts using this open multiple temp files and
are part of or used by autotools which may be run on MPs.
>> possible bashism in /bin/bzgrep line 66 (${parm/?/pat[/str]}):
>> j=${i//\\/}
>
> First real problem. Except that 'grep j= /bin/bzgrep' has no hits on my
> system with bzip2-1.0.6-2 installed; what version was this problem in?
Cygwin patch release 1.0.6-3 installed 2017-02-24 but unchanged since 2007:
$ ls -ghlo bzip2-1.0.6-3.src/bzip2-1.0.6/bzgrep
-rw-r--r--+ 1 1.7K Jan 2 2007 bzip2-1.0.6-3.src/bzip2-1.0.6/bzgrep
$ file /bin/bz{cmp,diff,less,more,*grep} # scripts from /etc/setup/bzip2.lst.gz
/bin/bzcmp: symbolic link to bzdiff
/bin/bzdiff: POSIX shell script, ASCII text executable
/bin/bzless: symbolic link to bzmore
/bin/bzmore: POSIX shell script, ASCII text executable
/bin/bzegrep: symbolic link to bzgrep
/bin/bzfgrep: symbolic link to bzgrep
/bin/bzgrep: POSIX shell script, ASCII text executable
$ fgrep -C9 j= bzip2-1.0.6-3.src/bzip2-1.0.6/bzgrep
for i do
if test -f "$i"; then :; else if test -f "$i.bz2"; then i="$i.bz2"; fi; fi
if test $list -eq 1; then
bzip2 -cdfq "$i" | $grep $opt "$pat" 2>&1 > /dev/null && echo $i
r=$?
elif test $# -eq 1 -o $silent -eq 1; then
bzip2 -cdfq "$i" | $grep $opt "$pat"
r=$?
else
j=${i//\\/}
j=${j//|/\\|}
j=${j//&/\\&}
j=`printf "%s" "$j" | tr '\n' ' '`
bzip2 -cdfq "$i" | $grep $opt "$pat" | sed "s|^|${j}:|"
r=$?
fi
test "$r" -ne 0 && res="$r"
done
exit $res
Judgement call whether to change shebang or spawn sed or other?
Debian release is 1.0.6-7, bzgrep dated 2014, and bash expressions
are gone, thanks to lintian and changes made to support more newer
grep options.
>> possible bashism in /bin/messagebus-config line 26 (should be '.',
>> not 'source'):
>> source ${CSIH_SCRIPT}
>
> Ah - now we get to an example file that is Cygwin-only (part of the
> Cygwin port of dbus, but reading that file makes it obvious that it
> is not from upstream) - where changing /bin/sh will cause breakage
> that we can't rely on Debian to have caught first.
--
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
Re: i686 ld couldn't resolve wglCreateContext from libopengl32.a on x86_64 system
On 2017-03-02 16:17, sorryforaskingthis.bk.ru via cygwin wrote:
$ gcc -o /tmp/conftest.exe /tmp/conftest.c -lopengl32
/tmp/ccec30zH.o:conftest.c:(.text+0xc): undefined reference to
`wglCreateContext'
conftest.c:
#ifdef __cplusplus
extern "C"
#endif
char wglCreateContext ();
int
main ()
{
return wglCreateContext ();
;
return 0;
}
This looks like a snippet of an autoconf AC_CHECK_LIB (or
AC_CHECK_FUNCTION) test. Such tests don't work with 32-bit Win32 APIs
-- on either Cygwin or MinGW -- because they don't take stdcall into
account. You'll need to modify the test to work around that.
Also, if you're using Cygwin, do you *really* want to be using Win32
OpenGL and not X11?
--
Yaakov
--
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
i686 ld couldn't resolve wglCreateContext from libopengl32.a on x86_64 system
I've done fresh install of cygwin with setup-x86.exe @ Win10 LTSB 2015 x64.
I've installed gcc-core and w32api-runtime packages.
opengl32.dll in System32 folder is 32-bit dll
With x86_64 install of cygwin ld able to find reference to wglCreateContext,
with x86 - not.
$ gcc -o /tmp/conftest.exe /tmp/conftest.c -lopengl32
/tmp/ccec30zH.o:conftest.c:(.text+0xc): undefined reference to
`wglCreateContext'
conftest.c:
#ifdef __cplusplus
extern "C"
#endif
char wglCreateContext ();
int
main ()
{
return wglCreateContext ();
;
return 0;
}
showing all JUNCTIONS as normal dirs as w/linux --bind (was Re: Cannot access volumes mounted with 'mklink...)
Corinna Vinschen wrote:
They
half-way work under Cygwin (junctions to volumes look like
mounted file systems look under linux, but junctions to
pathnames get converted by cygwin to symlinks -- losing
information when such junctions are restored.
Corinna -- could you _please_ re-look at supporting both
types of junctions as mount points? Then Cygwin could have
"mount-parity" with linux! ;-)
That's not easily possible. Mount points in Cygwin are virtual entries
stored in the per-user session, in-memory mount table.
---
Ahh.. you are making it more complicated than what I'm
asking! (yey! this should be simpler)...
If I have a junction to the root of another volume, in
cygwin it looks like a normal directory:
Using mountvol...
C:\>mountvol mountedVol \\?\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}
03/02/2017 01:24 PM mountedVol
[\??\Volume{578b2172-f917-11e4-b3d9-a0369f15ce28}\]
01/11/2017 04:17 PM var [C:\Windows\System32\cygwin\var]
### a junction is created ... under Cygwin.
Note, BTW, that 'var' is also a JUNCTION (a MS-mount point).
C:\>exit
exit
/> ll
total 100672654
drwxrwx---+ 10 Nov 20 2010 $RECYCLE.BIN/
...
drwxrwx---+ 10 May 15 2015 mountedVol/
lrwxrwxrwx 1 28 Jan 11 16:17 var ->
/Windows/System32/cygwin/var/
/> ls mountedVol
$RECYCLE.BIN/ System Volume Information/
### mountedVol looks like a normal directory ^^^, but 'var' shows
### as a symlink. That's the problem I'm referring to. I'm saying
### JUNCTIONs (MS-mountpoints) should show up as the 'same' in
### Cygwin -- i.e. --
### But is not necessary that it be shown in Cygwin's "mount table":
/> mount
C:/bin on /usr/bin type ntfs (binary,auto)
C:/lib on /usr/lib type ntfs (binary,auto)
C: on / type ntfs (binary,auto)
B: on /b type smbfs (binary,user,noumount,auto)
...
It's the same on linux.
linux> stat -c %D /var
822
linux> sudo mount --rbind /var/rtmp /tmp
linux> stat -c %D /tmp
822
A mount from the same fs to another place on the same fs,
looks like a normal directory (not a symlink).
This is the behavior I would want for 'JUNCTION's under
Cygwin.
On Windows, mklink creates a 'SYMLINK' or 'SYMLINKD' when
directories are linked. Those would stay as "Symlinks".
--
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] Updated: dash-0.5.9.1-1
On 03/02/2017 11:28 AM, Brian Inglis wrote:
> summary of checkbashisms -f run on 140 POSIX shell scripts as
> identified by file in my Cygwin 64 /bin/ with 784 packages (about 20%
> of cygwin-pkg-maint, 8% of setup.ini) installed, 70 possible issues
> (some from wrapped scripts because of -f):
Looking through some of the output, I already spot a few interesting things:
> possible bashism in /bin/autoconf-2.69 line 55 ($BASH_SOMETHING):
> if test -z "$BASH_VERSION$ZSH_VERSION" \
> && (test "X`print -r -- $as_echo`" = "X$as_echo") 2>/dev/null; then
Not a problem - the script is probing whether it needs to do something
based on being bash or not, but is written with all shells in mind.
> error: /bin/autoconf-2.69: Unterminated quoted string found, EOF reached.
> Wanted: <'>, opened in line 429
bug in checkbashisms; looks like it happens in several places in the output
> possible bashism in /bin/autopoint line 57 ($RANDOM):
> tmp=$TMPDIR/gt$$-$RANDOM
Not a problem - the script is using $RANDOM for an additional level of
safety, but works safely even when $RANDOM is the empty string (as on dash).
> possible bashism in /bin/bzgrep line 66 (${parm/?/pat[/str]}):
> j=${i//\\/}
First real problem. Except that 'grep j= /bin/bzgrep' has no hits on my
system with bzip2-1.0.6-2 installed; what version was this problem in?
> possible bashism in /bin/messagebus-config line 26 (should be '.', not
> 'source'):
> source ${CSIH_SCRIPT}
Ah - now we get to an example file that is Cygwin-only (part of the
Cygwin port of dbus, but reading that file makes it obvious that it is
not from upstream) - where changing /bin/sh will cause breakage that we
can't rely on Debian to have caught first.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
Eric Blake writes: > To reiterate my answer in different terms: > > If you can convince Fedora to switch /bin/sh to dash, then I will > immediately follow in Cygwin. Until then, I'm worried that there are > enough scripts in the wild that use bashisms and will therefore break if > /bin/sh is not bash, even though that number has reduced somewhat since > Debian made their switch. Trying to make Cygwin the guinea pig, instead > of Fedora, is going about it backwards (you WANT the change to be done > in a place where there is plenty of manpower to deal with the fallout, > and Fedora has more manpower than Cygwin). Ack. I want to put forward that we should get the postinstall scripts moved from bash to dash as a first step even then. > I'm still toying with the idea of doing a test release of both bash and > dash that flips /bin/sh between them; but I'm still stuck on the problem > that a user MUST upgrade (or downgrade) both packages in tandem, or else > risk being left without a /bin/sh at all. Help would be appreciated in > figuring out the problem (telling me that "dash is faster than bash" is > not help, nor is telling me that "portable shell scripts don't care if > /bin/sh is bash or dash" - I already know those points. What I don't > know is how many non-portable scripts are out there, so how much > breakage would I be causing by forcing those non-portable scripts to > deal with their non-portability, and how to minimize the even-worse > breakage of an upgrade scenario that leaves no /bin/sh at all). I'd test that in production. I don't really need handholding w.r.t. update and potential downgrade process, so if you'd put the two packages somewhere into an unofficial repo that would work for me. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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] tzcode/tzdata 2017a-1
The following packages have been uploaded to the Cygwin distribution: * tzcode-2017a-1 * tzdata-2017a-1 The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative locations around the globe. It is updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules. This is an update to the latest upstream release: https://mm.icann.org/pipermail/tz-announce/2017-February/45.html -- Yaakov -- 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] MATE Desktop 1.16
The following packages have been uploaded to the Cygwin distribution: * atril-1.16.1-1 * caja-1.16.2-1 * caja-actions-1.8.2-1 * caja-extensions-1.16.0-1 * caja-follow-symlink-1.2.0-4 * caja-python-1.16.0-1 * engrampa-1.16.0-1 * eom-1.16.1-1 * eom-plugins-1.16.0-1 * libmatekbd-1.16.0-1 * libmatemixer-1.16.0-1 * libmateweather-1.16.0-1 * marco-1.16.0-1 * mate-applets-1.16.0-1 * mate-backgrounds-1.16.0-1 * mate-common-1.16.0-1 * mate-control-center-1.16.1-1 * mate-desktop-1.16.1-1 * mate-dictionary-1.16.0-1 * mate-disk-usage-analyzer-1.16.0-1 * mate-icon-theme-1.16.0-1 * mate-indicator-applet-1.16.0-1 * mate-media-1.16.0-1 * mate-menus-1.16.0-1 * mate-notification-daemon-1.16.1-1 * mate-panel-1.16.1-1 * mate-screenshot-1.16.0-1 * mate-search-tool-1.16.0-1 * mate-session-manager-1.16.1-1 * mate-settings-daemon-1.16.1-1 * mate-system-log-1.16.0-1 * mate-system-monitor-1.16.0-1 * mate-terminal-1.16.2-1 * mate-themes-3.18.5-1 * mate-user-guide-1.16.0-1 * mozo-1.16.0-1 * pluma-1.16.0-1 * pluma-plugins-1.16.0-1 * xplayer-1.2.2-1 The MATE Desktop Environment is the continuation of GNOME 2. It provides an intuitive and attractive desktop environment using traditional metaphors for Linux and other Unix-like operating systems. This is an update to the latest upstream stable release, with a complete switch to GTK+3. -- Yaakov -- 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
/usr/bin/time -v (or -f=%M) is 64 times what it should be
This is probably another page size/count miscalculation. I use that field for benchmarking, so it means adding a Cygwin-specific hack to make the scripts portable to other Posix systems. Cheers, Marty -- 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
/usr/bin/top: RES and MEM% are 16 times VIRT
The RES column displayed by /usr/bin/top is 16 times as large as VIRT (as is MEM%, since it is presumably calculated from RES). From my observations, VIRT seems to agree with /proc/self/stat field 22 (0-origin), and matches what I expect. Not a big deal, but it surprised the heck out of me If I were to guess, I'd say this is probably due to incorrect page size/count calculations. Cheers, Marty -- 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] Updated: dash-0.5.9.1-1
On 2017-03-02 07:29, Eric Blake wrote:
> On 03/02/2017 07:36 AM, Marco Atzeri wrote:
>> On 02/03/2017 13:36, Steven Penny wrote:
>>> On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote:
Then you haven't been paying attention. And I didn't even
attempt to make an argument one way or the other, except to say
stop arguing. The horse is dead.
>>>
>>> Perhaps you could link to a constructive, concrete idea against
>>> the change that someone has made besides Eric. Even better, you
>>> could post your own constructive idea; surely you havent emailed
>>> twice now with nothing constructive to add?
>>
>> He was constructive, but you seems biased in understanding the answer.
>
> To reiterate my answer in different terms:
>
> If you can convince Fedora to switch /bin/sh to dash, then I will
> immediately follow in Cygwin. Until then, I'm worried that there are
> enough scripts in the wild that use bashisms and will therefore break if
> /bin/sh is not bash, even though that number has reduced somewhat since
> Debian made their switch. Trying to make Cygwin the guinea pig, instead
> of Fedora, is going about it backwards (you WANT the change to be done
> in a place where there is plenty of manpower to deal with the fallout,
> and Fedora has more manpower than Cygwin).
I can see distros like *BSD or Debian making decisions like that or
systemd, but not vendors like RH or Canonical: too little upside with
too much downside for paying customers.
> I'm still toying with the idea of doing a test release of both bash
> and dash that flips /bin/sh between them; but I'm still stuck on the
> problem that a user MUST upgrade (or downgrade) both packages in
> tandem, or else risk being left without a /bin/sh at all. Help would
> be appreciated in figuring out the problem (telling me that "dash is
> faster than bash" is not help, nor is telling me that "portable shell
> scripts don't care if /bin/sh is bash or dash" - I already know those
> points. What I don't know is how many non-portable scripts are out
> there, so how much breakage would I be causing by forcing those
> non-portable scripts to deal with their non-portability, and how to
> minimize the even-worse breakage of an upgrade scenario that leaves
> no /bin/sh at all).
summary of checkbashisms -f run on 140 POSIX shell scripts as
identified by file in my Cygwin 64 /bin/ with 784 packages (about 20%
of cygwin-pkg-maint, 8% of setup.ini) installed, 70 possible issues
(some from wrapped scripts because of -f):
14 /bin/cronbug
7 /bin/procmail-config
5 /bin/ca-legacy
4 /bin/pcdovtoppm
3 /bin/ppmshadow
3 /bin/ppmfade
3 /bin/fig2ps2tex
3 /bin/bzgrep
2 /bin/ppmrainbow
2 /bin/pnmquant
2 /bin/pnmflip
2 /bin/install-catalog
1 /bin/zgrep
1 /bin/zdiff
1 /bin/xzdiff
1 /bin/updatedb
1 /bin/texi2dvi
1 /bin/ppmquant
1 /bin/pnmquantall
1 /bin/pic2graph
1 /bin/pgmcrater
1 /bin/pdfroff
1 /bin/messagebus-config
1 /bin/gzexe
1 /bin/grap2graph
1 /bin/gettextize
1 /bin/gettext.sh
1 /bin/eqn2graph
1 /bin/clisp-link
1 /bin/ccmakedep
1 /bin/autopoint
1 /bin/autoconf-2.69
with diagnostics (some from wrapped scripts because of -f):
16 echo -e
12 '((' should be '$(('
7 alternative test command ([[ foo ]] should be [ foo ])
7 $RANDOM
6 unsafe echo with backslash
5 'function' is useless
4 type
4 bash arrays, ${name[0|*|@]}
3 ${parm/?/pat[/str]}
3 $_
1 should be '.', not 'source'
1 $BASH_SOMETHING
1 $(OS|MACH)TYPE
So about 20% of packages have scripts installed, with potential issues
ranging from 5-12*70 == 350-840.
Some potential fixes are obvious from my sample (attached, hopefully
as inline text which will pass thru the filters):
- change these scripts to shebang #!/bin/bash
- replace echo -e with printf in most cases
- replace [[ ... ]] with [ ... ] or case if patterns are used
- strip leading function
- use mktemp to eliminate $RANDOM
but most require judgement in application.
Generated scripts like libtool{,ize} may require complex patches submitted
upstream to fix what may be sh dependent code generation or execution; not
included in the attached sample, as file categorized these as:
/bin/libtool:POSIX shell script, ASCII text executable, with very long
lines, with escape sequences
/bin/libtoolize: POSIX shell script, ASCII text executable, with very long
lines, with escape sequences
> Hmm, maybe I could create a NEW package, 'sh', which packages /bin/sh as
> however I want it (probably bash to begin with, to at least give people
> time to upgrade and pick up the packaging change before also having to
> deal with any shell changing). New releases of both bash and dash would
> depend on the new package, to guarantee that if you upgrade one shell,
> you pick up the dependency. And by not hav
RE: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
From: Eric Blake > ... > Until then, I'm worried that there are > enough scripts in the wild that use bashisms and will therefore break if > /bin/sh is not bash, even though that number has reduced somewhat since > Debian made their switch. > ... I was thinking of testing my scripts by changing sh to be a link to dash, but ran into the following: $ which sh bash dash /usr/bin/sh /usr/bin/bash /usr/bin/dash $ ls -ld /usr/bin/*sh lrwxrwxrwx 1 knellis Domain Users8 Dec 1 11:38 /usr/bin/csh -> tcsh.exe -rwxr-xr-x 1 knellis Domain Users 4287 Jan 15 07:53 /usr/bin/instmodsh lrwxrwxrwx 1 knellis Domain Users 12 May 26 2015 /usr/bin/tclsh -> tclsh8.5.exe $ Why don't I see sh, bash, or dash? But then I tried: $ ls -ld /usr/bin/*sh.exe -rwxr-xr-x 2 knellis Domain Users 100883 Feb 17 08:47 /usr/bin/ash.exe -rwxr-xr-x 2 knellis Domain Users 739859 Jan 27 14:13 /usr/bin/bash.exe -rwxr-xr-x 2 knellis Domain Users 100883 Feb 17 08:47 /usr/bin/dash.exe -rwxr-xr-x 1 knellis Domain Users 11795 Aug 18 2013 /usr/bin/rsh.exe -rwxr-xr-x 2 knellis Domain Users 739859 Jan 27 14:13 /usr/bin/sh.exe -rwxr-xr-x 1 knellis Domain Users 650771 Dec 20 06:57 /usr/bin/ssh.exe -rwxr-xr-x 1 knellis Domain Users 372755 Nov 24 11:07 /usr/bin/tcsh.exe $ Another unexpected result from Cygwin's .exe magic. --Ken Nellis
Re: ld internal script has wrong SEARCH-DIR settings
On 2017-03-02 09:05, sorryforaskingthis.bk.ru via cygwin wrote:
$ ./ld --verbose
[snip]
OUTPUT_FORMAT(pei-i386)
SEARCH_DIR("/usr/i686-pc-cygwin/lib"); SEARCH_DIR("/usr/lib");
SEARCH_DIR("/usr/lib/w32api");
There is no libraries under /usr/i686-pc-cygwin/lib or /usr/lib or
/usr/lib/w32api
Instead, they located at /usr/i686-w64-mingw32/sys-root/mingw/lib; /lib and
/lib/w32api accordingly
/usr/lib == /lib, unless your mounts are messed up.
--
Yaakov
--
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
ld internal script has wrong SEARCH-DIR settings
$ ./ld --verbose
GNU ld (GNU Binutils) 2.25.2
Supported emulations:
i386pe
using internal linker script:
==
/* Default linker script, for normal executables */
/* Copyright (C) 2014 Free Software Foundation, Inc.
Copying and distribution of this script, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved. */
OUTPUT_FORMAT(pei-i386)
SEARCH_DIR("/usr/i686-pc-cygwin/lib"); SEARCH_DIR("/usr/lib");
SEARCH_DIR("/usr/lib/w32api");
There is no libraries under /usr/i686-pc-cygwin/lib or /usr/lib or
/usr/lib/w32api
Instead, they located at /usr/i686-w64-mingw32/sys-root/mingw/lib; /lib and
/lib/w32api accordingly
I've used 2.877 version of cygwin setup-x86.exe
$ cygcheck -c
Cygwin Package Information
Package Version Status
List of installed packages:
_autorebase 001004-1 OK
alternatives 1.3.30c-10 OK
autoconf 13-1 OK
autoconf2.1 2.13-12 OK
autoconf2.5 2.69-3 OK
base-cygwin 3.8-1 OK
base-files 4.2-4 OK
bash 4.4.12-3 OK
binutils 2.25-4 OK
bzip2 1.0.6-3 OK
ca-certificates 2.11-1 OK
coreutils 8.26-2 OK
csih 0.9.9-1 OK
cygrunsrv 1.62-1 OK
cygutils 1.4.15-2 OK
cygwin 2.7.0-1 OK
cygwin-devel 2.7.0-1 OK
dash 0.5.9.1-1 OK
desktop-file-utils 0.23-1 OK
diffutils 3.5-2 OK
editrights 1.03-1 OK
file 5.25-1 OK
findutils 4.6.0-1 OK
gamin 0.1.10-15 OK
gawk 4.1.4-3 OK
gcc-core 5.4.0-1 OK
gcc-g++ 5.4.0-1 OK
gcc-objc 5.4.0-1 OK
getent 2.18.90-4 OK
gettext 0.19.8.1-2 OK
gettext-devel 0.19.8.1-2 OK
git 2.8.3-1 OK
grep 3.0-2 OK
groff 1.22.3-1 OK
gsettings-desktop-schemas 3.18.1-1 OK
gzip 1.8-1 OK
hostname 3.13-1 OK
info 6.1-2 OK
ipc-utils 1.0-1 OK
less 481-1 OK
libargp 20110921-3 OK
libatomic1 5.4.0-1 OK
libattr1 2.4.46-1 OK
libblkid1 2.25.2-2 OK
libbz2_1 1.0.6-3 OK
libcharset1 1.14-3 OK
libcom_err2 1.42.12-2 OK
libcroco0.6_3 0.6.11-1 OK
libcrypt0 1.4-1 OK
libcurl4 7.52.1-1 OK
libdb4.8 4.8.30-1 OK
libdb5.3 5.3.28-1 OK
libedit0 20130712-1 OK
libexpat1 2.2.0-0 OK
libfam0 0.1.10-15 OK
libffi6 3.2.1-1 OK
libgcc1 5.4.0-1 OK
libgdbm4 1.12-1 OK
libglib2.0_0 2.46.2-4 OK
libgmp10 6.1.2-1 OK
libgnutls28 3.3.17-1 OK
libgomp1 5.4.0-1 OK
libgssapi_krb5_2 1.14.4-1 OK
libguile17
Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
On 2017-03-02 06:36, Marco Atzeri wrote: > On 02/03/2017 13:36, Steven Penny wrote: >> On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote: >>> Then you haven't been paying attention. And I didn't even attempt >>> to make an argument one way or the other, except to say stop >>> arguing. The horse is dead. >> >> Perhaps you could link to a constructive, concrete idea against >> the change that someone has made besides Eric. Even better, you >> could post your own constructive idea; surely you havent emailed >> twice now with nothing constructive to add? > > He was constructive, but you seems biased in understanding the > answer. > > ~ 70% of (weighted*) package managers rejected the proposal > already here: > > https://cygwin.com/ml/cygwin/2017-02/msg00310.html > https://cygwin.com/ml/cygwin/2017-02/msg00295.html > > And I agree with them; we have no bandwith/resources > to handle it. That makes it over 75% and we can appreciate your efforts and viewpoint. I will just have to continue using my Cygwin setup check and fixup profile script. -- 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
Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
On 03/02/2017 07:36 AM, Marco Atzeri wrote: > On 02/03/2017 13:36, Steven Penny wrote: >> On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote: >>> Then you haven't been paying attention. >>> And I didn't even attempt to make an argument one way or the other,=20 >>> except to say stop arguing. The horse is dead.= >> >> Perhaps you could link to a constructive, concrete idea against the >> change that >> someone has made besides Eric. Even better, you could post your own >> constructive >> idea; surely you havent emailed twice now with nothing constructive to >> add? > > He was constructive, but you seems biased in understanding the answer. To reiterate my answer in different terms: If you can convince Fedora to switch /bin/sh to dash, then I will immediately follow in Cygwin. Until then, I'm worried that there are enough scripts in the wild that use bashisms and will therefore break if /bin/sh is not bash, even though that number has reduced somewhat since Debian made their switch. Trying to make Cygwin the guinea pig, instead of Fedora, is going about it backwards (you WANT the change to be done in a place where there is plenty of manpower to deal with the fallout, and Fedora has more manpower than Cygwin). I'm still toying with the idea of doing a test release of both bash and dash that flips /bin/sh between them; but I'm still stuck on the problem that a user MUST upgrade (or downgrade) both packages in tandem, or else risk being left without a /bin/sh at all. Help would be appreciated in figuring out the problem (telling me that "dash is faster than bash" is not help, nor is telling me that "portable shell scripts don't care if /bin/sh is bash or dash" - I already know those points. What I don't know is how many non-portable scripts are out there, so how much breakage would I be causing by forcing those non-portable scripts to deal with their non-portability, and how to minimize the even-worse breakage of an upgrade scenario that leaves no /bin/sh at all). Hmm, maybe I could create a NEW package, 'sh', which packages /bin/sh as however I want it (probably bash to begin with, to at least give people time to upgrade and pick up the packaging change before also having to deal with any shell changing). New releases of both bash and dash would depend on the new package, to guarantee that if you upgrade one shell, you pick up the dependency. And by not having /bin/sh in either the bash or dash package, then we would at least avoid the current situation where upgrading/downgrading in the wrong order could leave a user without /bin/sh at all. You might still be in a situation where the wrong version of the 'sh' package leaves you with an outdated version of a shell, or the wrong flavor in relation to the current distro choice, but that's less of a problem than having no /bin/sh at all. In fact, having a separate 'sh' package may make it even easier to pick which shell flavor you prefer (if I always keep the 'curr' and 'test' versions pointed to different shells, then you make the choice of which sh flavor you want by which version you install). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] Updated: dash-0.5.9.1-1
On 02/03/2017 13:36, Steven Penny wrote: On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote: Then you haven't been paying attention. And I didn't even attempt to make an argument one way or the other,=20 except to say stop arguing. The horse is dead.= Perhaps you could link to a constructive, concrete idea against the change that someone has made besides Eric. Even better, you could post your own constructive idea; surely you havent emailed twice now with nothing constructive to add? He was constructive, but you seems biased in understanding the answer. ~ 70% of (weighted*) package managers rejected the proposal already here: https://cygwin.com/ml/cygwin/2017-02/msg00310.html https://cygwin.com/ml/cygwin/2017-02/msg00295.html And I agree with them; we have no bandwith/resources to handle it. Regards Marco * https://www.cygwin.com/cygwin-pkg-maint -- 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] Updated: dash-0.5.9.1-1
On Wed, 1 Mar 2017 23:31:24, Vince Rice wrote: Then you haven't been paying attention. And I didn't even attempt to make an argument one way or the other,=20 except to say stop arguing. The horse is dead.= Perhaps you could link to a constructive, concrete idea against the change that someone has made besides Eric. Even better, you could post your own constructive idea; surely you havent emailed twice now with nothing constructive to add? -- 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
