Re: OpenGL-1.1.0 compile problem in cygwin-1.7
Phan, Linh H wrote: gluTessCallback(tobj, (GLenum)GLU_BEGIN, (void (*)())glBegin); gluTessCallback(tobj, (GLenum)GLU_END, glEnd); gluTessCallback(tobj, (GLenum)GLU_VERTEX, (void (*)())glVertex2fv); } And that fixed it for glEnd, but I don't know how to fix the glBegin and glVertex2fv. This is not my code; it's part of the SGI OpenInventor library. You can use a typedef to make life a little easier. There's already one in glu.h that you can reuse (although it looks like it's not meant to be part of the public interface so it might not be the best idea to rely on it): typedef void (APIENTRY *_GLUfuncptr)(); Then the cast becomes just (_GLUfuncptr)whatever. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).
Eric Blake wrote: Oops. m4_append was undocumented in 2.60, then changed semantics in autoconf 2.62. Newer libtool works around the semantic change by using lt_append, not m4_append: http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=5b560bd But you still have the definition of lt_if_append_uniq from older libtool, which doesn't work with newer autoconf. I guess this means no one has yet identified this as one of the fixes that needs to be imported as part of future- proofing the gcc tree to make the eventual transition to newer autotools easier. Do you feel like opening a gcc incident with this email chain as the starting point? This is already fixed on the gcc mainline, which has ltsugar.m4 serial 6, from libtool 2.2.6. As to the version check, that's another thing that is not on the 4.3 branch but is present on mainline (see config/override.m4.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Latest autoconf (2.63): problem generating libtool script when reconfiguring GCC (maybe others).
Charles Wilson wrote: and thus make it easier to move officially to 2.6x at some point in the future, are still in work. BTW, Ralf expressed a tentative plan to work on this after 4.4 has branched and mainline returns to stage 1: http://gcc.gnu.org/ml/gcc/2008-12/msg00048.html. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: OpenGL-1.1.0 compile problem in cygwin-1.7
Phan, Linh H wrote: /usr/include/sys/_types.h:63:20: error: stddef.h: No such file or directory In file included from /usr/lib/../include/w32api/glui.h:29, from example1.cpp:20: /usr/include/stdio.h:37:20: error: stdarg.h: No such file or directory In file included from /usr/include/sys/reent.h:14, from /usr/include/string.h:11, from example1.cpp:18: /usr/include/sys/_types.h:72: error: 'wint_t' does not name a type In file included from example1.cpp:18: /usr/include/string.h:22: error: 'size_t' has not been declared stddef.h and stdarg.h aren't part of Cygwin and they don't live in /usr/include. They are provided by the compiler and they should be found in the compiler's private include directory, $libdir/gcc/$target/$version/include. If it's not found you have an installation problem with gcc. Try the following to verify: $ echo #include stdarg.h | gcc -x c - -H -E -o /dev/null . /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/stdarg.h Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: OpenGL-1.1.0 compile problem in cygwin-1.7
Phan, Linh H wrote: $ /usr/bin/g++ -g -c -I/usr/include/opengl test.c++ x.c++: In function `void test()': x.c++:7: error: invalid conversion from `void (*)()' to `void (*)()' x.c++:7: error: initializing argument 3 of `void gluTessCallback(GLUtesselator*, GLenum, void (*)())' x.c++:8: error: invalid conversion from `void (*)()' to `void (*)()' x.c++:8: error: initializing argument 3 of `void gluTessCallback(GLUtesselator*, GLenum, void (*)())' x.c++:9: error: invalid conversion from `void (*)()' to `void (*)()' x.c++:9: error: initializing argument 3 of `void gluTessCallback(GLUtesselator*, GLenum, void (*)())' Here you are using the Win32 API version of these functions, and the Win32 API generally uses the stdcall calling convention throughout, including the callback. C++ is very strict about types and it does not consider pointer to function taking no args and returning void using cdecl calling convention and pointer to function taking no args and returning void using stdcall calling convention to be compatible types. It's just that the diagnostic doesn't display the calling convention attribute of the type, so it only looks like they're the same type from the message. Moreover, the compiler is right to be picky because calling convention is a fundamental aspect of the function -- it's not something that can be fixed by just changing to the correct cast. In this case since glBegin et al. are also Win32 API functions they have the proper calling convention, so you only need to fix the cast. But if you were actually implementing the callback in your code, you would have to both explicitly ensure that it was is defined with the correct calling convention, in addition to using the proper cast. But I can compile it if I use the /usr/X11R6/include/GL: $ /usr/bin/g++ -g -c -I/usr/X11R6/include test.c++ $ Here you're using the X11 version of the API, which uses the default cdecl calling convention throughout. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Problems with remote programs using ncurses (aptitude)
SO wrote:
I have problems opening remote programs using ncurses library.
Aptitude for example. Menus and other interface components are just
garbage on my term on windows vista. Is there a solution for that?
The answer will depend on what terminal you're using. But first a
summary of the problem: The application wants to draw nice looking boxes
or lines. So it checks the value of the TERM environment variable and
then asks its local terminfo database what the appropriate characters
are for that terminal, and prints them. Simple, so far.
The problem is that Cygwin terminals are all codepage-based, not
Unicode. (There is a rxvt-unicode package, but does not actually
support Unicode yet.) A codepage-based program is restricted to only
being able to output characters in that codepage, which is pretty much
the whole reason in a nutshell why Unicode was invented and is so
superior.
But anyway the default Windows codepage for most systems does *not*
include the line drawing characters. For example, most western locales
use Windows-1252:
http://www.microsoft.com/globaldev/reference/sbcs/1252.mspx. Compare
this to codepage 437, which is sometimes called the OEM codepage
because it corresponds to the one originally used on the original IBM
PC: http://www.microsoft.com/globaldev/reference/oem/437.mspx. Hey
look, line drawing characters! If you look in slot C4 for example
you'll a horizontal line, and then look in the same slot in CP-1252 and
you'll see LATIN CAPITAL LETTER A WITH DIAERESIS, which explains why you
see Ä where you should see a horizontal line, because the terminfo entry
was written with CP437 in mind.
So one solution is to switch to that codepage. If and only if you are
using the Cygwin terminal, then you can do this by adding codepage:oem
to your CYGWIN environment variable, and everything should work. Except
of course if you need to actually view any text with those Latin
accented characters.
If you are using something other than the built-in Cygwin terminal, then
you need a different solution. If you are using rxvt in non-X11 mode,
you can try using the built-in Windows font 'Terminal':
rxvt -fn Terminal -tn rxvt-cygwin-native -e /bin/bash -li
Another alternative (again, for non-X rxvt) is to use a font that is
hacked up to pretend to be CP1252 except it's got the line drawing
glyphs subsituted in those slots. Google the list archives for
luconP.zip which is a verion of Lucida Console appropriately
modified. After installing this font you should invoke rxvt with
something like:
rxvt -fn Lucida ConsoleP-14 -tn rxvt-cygwin-native -e /bin/bash -li
You can modify the -14 to select the desired font size. And again this
assumes you are using non-X rxvt -- if you're using it in X11 mode you
could do something similar (find and specify a font with line drawing
characters) except you would want the terminal name set to rxvt-cygwin
without -native.
Another solution would be to use a unicode terminal, with the
appropriate setting of TERM. This means using a non-Cygwin application
which unfortunately usually means pain because they don't play well with
Cygwin's pty emulation, but I'm fairly sure there are some out there
that work (poderosa?) or have been specially modified to work
(cygputty).
Another solution is to instead of changing terminals, just select a
different value of TERM, i.e. *tell* the remote end you're using a
different terminal. The goal here is to select something that is close
enough to your terminal that it shares a common set of control codes,
but doesn't try to use the line drawing chars. This can be hit and
miss, as you're really lying by saying you're using a different terminal
than the one you really are, but it can be a quick solution. For
example you might try:
$ TERM=linux-lat aptitude
(This linux-lat terminfo entry is described as linux with latin1 or
latin2 alternate character set and it conveniently has all the line
drawing stuff disabled so you'll just see blanks instead.)
And one more possible workaround: take the terminfo entry for your
terminal and modify it to use boring Latin ASCII characters (e.g. + | -
etc) for line drawing. This is better than the last alternative as you
can rest assured that all the other capabilities should work correctly
as you're just copying the existing one and modifying it. Here is an
example that does this with the rxvt-cygwin-native terminfo entry:
$ infocmp -1 rxvt-cygwin-native | \
perl -pe 's@(rxvt-cygwin-native)@$1-latin@;' \
-e '[EMAIL PROTECTED]@acsc=!g#w*q+x\\,-s.vm{`_0a\\:fh#}f~p|,@;' \
/tmp/term.tmp \
tic -o ~/.terminfo /tmp/term.tmp \
rm /tmp/term.tmp
This creates a new terminal called rxvt-cygwin-native-latin, compiles
it, and installs it under your home directory in $HOME/.terminfo. This
is useful because terminfo applications look there first before the
system location /usr/share/terminfo. You can now use this by changing
your rxvt startup shortcut to specify -tn
Re: all files seems to be owned by the actual user
Matthias Meyer wrote: I've tried also ntsec, binmode and . Why are you doing these things? Are you following somebody's guide? Please tell them that they are spreading useless information if that is the case. ntsec is the default. binmode is the default and is irrelevant for files anyway. So is the same as ntsec binmode, and you should not need to set CYGWIN at all in general unless there is a *specific* reason that calls for it. All of this three list the true file owner with ls -anlh. But as before, rsync -a create the files with the user who runs the rsync command. Also rsync -aA with or without --numeric-ids have this behaviour. I would believe that I have a very stupid failure. I can not believe that it is not possible to backup and restore the file owner. rsync only tries to set the owner when it thinks it has the privilege to do so -- on most POSIX systems this means being the superuser, uid=0. This check in rsync is less than useful on Cygwin where privileges work differently. Thankfully they provide an override in the form of the --super switch. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gdb is sooooo slow - is that normal?
John Emmas wrote: That shows 5 stages out of maybe 20 or so that seem to run before my own app appears on screen. The problem is that each of those stages can take anywhere from about 6 seconds up to 15 seconds (taking longer, the more breakpoints I've set). Therefore after starting the debug process, it can take between 2 minutes and maybe 6 minutes before my app gets launched. Is this normal for Cygwin? The more complex the app, the worse the problem is. If I set more than about 5 breakpoints with a complicated app, the debugger takes so long to get going that it becomes not worth waiting. Does anyone else find this? I'd like to find out whether it's a problem with Cygwin or with CodeBlocks. No, that's certainly not normal. Try the same commands directly in Cygwin's packaged gdb with CodeBlocks completely removed from the picture and see if it's the same speed. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: all files seems to be owned by the actual user
Matthias Meyer wrote: Please can you say what I have to do? Should rsync -a --super /cygdrive/c/data /cygdrive/c/backup do the job what I want? Yes, that ought to work. Does it? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync restore the file owner but rsyncd do it not
Matthias Meyer wrote: My first questions: What the reason for not copying the attributes HS? rsync is a POSIX program. It sees everything in terms of POSIX. That means it sees a file mode, such as 0644, 0755, etc. It reads a mode on the source and sets that same mode on the dest, that is it. It has no idea what H/S/R/A attributes mean or that they even exist. The A attribute gets set on the dest file simply because that is the default behavior when creating a file. The R attribute gets set because Cygwin can map that bit easily onto the POSIX u=w mode bit, such that setting a mode like 0444 will cause R to be set and setting 0644 will cause R to be reset. But S and H have no such easy mapping onto POSIX modes, so they aren't propagated. If I try -X I get an error rsync: extended attributes are not supported on this client Any EA support in rsync would most likely be some form of POSIX EA anyway, not R/H/S/A, so I don't think this really matters. The same behavior occurs with a file test.txt which is owned by: ls -al shows - user mkgroup ls -an shows - 1006 513 http://cygwin.com/faq/faq-nochunks.html#faq.using.chmod Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygport and gpg
Ken Brown wrote: I don't use gpg, but a look at the documentation suggests that I'm supposed to import a public key. Should the key have been included with the source package? I didn't see it there. No, keys are available from keyservers. You ought to be able to import it automatically with gpg --search-keys 671B682D. If that doesn't work then you might need to configure a keyserver but I'm pretty sure gpg ships with a default one preset. It appears that in recent versions (0.9.1 and on) of cygport, failure to verify has been made informational and not fatal. But trunk versions of cygport are for cygwin 1.7 only so it looks like 1.5 will only ever see 0.4.x. Anyway, it's just a script. You can edit the line in __gpg_verify where it invokes gpg --verify to add || true on the end if you can't import the key. Or you can just remove the .sig file, or rename it to some other extension so it's not seen. A google search turned up a similar gpg error message in http://www.cygwin.com/ml/cygwin-apps/2008-10/msg00075.html , but that post never got a response. In that message the failure to verify was just informational (using 0.9.x), the actual problem that caused the build to fail was the inability for rsync to copy the source tree successfully. So, unrelated. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: all files seems to be owned by the actual user
Matthias Meyer wrote: Another strangely effect is that ls -alnh / lists all files as owned by the actual user. If I do that as another user the files will also be listet as owned by him, the user who runs the ls. What is the reason for that? You instructed Cygwin to not read or write any ACLs by setting nontsec. It has to fill in those fields with something so it just lists whatever the current user is as the owner (just as it would have had to do with a filesystem like FAT or an OS like Win95 that doesn't record an owner.) Is there a possibility to backup the files from different users (e.g. with rsync) and restore them with the same owner and permissions which they have at backup time? Certainly not with nontsec in effect. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin/Python question: NumPy
Gustavo Seabra wrote: I have installed all the python packages available from setup.exe, which includes NumPy. However, I am trying to install another program Are you sure about that? There's only Numeric available through setup, not NumPy. Maybe you are thinking of Cygwin Ports, which does have a python-numpy package. But that's a separate project. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CYGWIN=ntsec, cp -a, and NT acls
Rob Walker wrote:
# make it read-only the windows way
attrib +R ${FILE}
Note that the +R attribute (and attributes in general) has nothing to do
with ACLs or security, it's a completely different concept. FAT for
instance supports R/H/S/A attributes but otherwise has a total lack of
any form of ACLs.
I think introducing the 'R' attribute really muddies this example,
because Cygwin sort-of honors it as if it reflected the contents of the
ACL, when it is a separate bit entirely. You can see this in your
example by adding some calls to getfacl. You'll see that attrib +R
didn't change any of the ACLs, but nevertheless Cygwin still reports it
without the +w bit in the ls output as 0555 mode, even though its ACL
still indicates write permission.
The output of the examination above shows me that cp -a doesn't
preserve Full Control for the owner on the copied file. Is this the
expected behavior under ntsec? If I use CYGWIN=nontsec, Full Control is
preserved.
Well cp is a POSIX program and it has no idea what Windows style NT ACLs
are. It preserves the Unix modes of the file, in other words it sees
0555 on the source file and 0555 on the destination file, so it's done
it's job as far as it's concerned. The problem of course is that there
is not a one to one mapping of Unix modes to NT ACLs, so there is more
than one way to express mode 0555.
With 'nontsec', Cygwin doesn't even bother setting any ACLs, so things
fall back to the default Windows way where the ACL is inherited from the
directory, which is the same way that things worked when you used a
Windows program to create the first copy of the file. So the two files
have identical ACLs not because of anything cp -a did or didn't do, but
because they were essentially both created in the same manner and both
inherited the default ACL of the containing directory.
Also, another thing to note is that Cygwin uses the backup privilege of
Administrator accounts to enable root-like unix semantics. On a nix
system if you are root you can do anything, regardless of permissions.
This is not so on Windows. If you've got a file with mode 555, meaning
there are no +w bits, then normal Windows tools won't be able to write
to it which is why you are getting the error.
Note the Access is denied. This is the issue I'm having. I need for
the Windows programs to view the file copy the same way they'd view the
original file.
To summarize, it seems to me that this is the situation: the source file
has an ACL that indicates writable permission but has the +R attribute
set, which Cygwin reflects as a mode of 0555. You tell cp to copy the
file and its mode, so it creates a new file and gives it mode 0555 as
well. This means it creates an ACL that denies write permission,
because hey, user asked for 0555. Since this is presumably an
administrator account, you can continue to write to the file using
Cygwin tools on account of its emulation of root, but you can't with
native tools because the ACL doesn't allow it.
This is obviously a contrived example. I don't need to use cmd /c
copy and cp interchangeably, but there are a bunch of native Windows
tools that have the same behavior as cmd /c copy. Cygwin's
interoperability with these are my problem.
So I guess my question is where is this wacky set +R attribute step
coming from? Or alternatively, why are you surprised that you ask to
create an unwritable file and get something that's not writable?
If you want something that actually copies ACLs, not just replicating
modes, then I guess you want to use getfacl/setfacl, e.g.
$ setfacl -f (getfacl ${FILE}) ${FILE}_copy
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Setup.exe: all files in one common directory? (not per-server)
sowiso wrote: Could it also be possible to have the release directory used together with _all_ mirrors? You should be able to just specify as the Local Package Dir the parent dir and it should find and union the contents of all the subdirs. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup.exe: all files in one common directory? (not per-server)
sowiso wrote: and so on. __I cannot do anything about this.__ You see? If I do want to avoid this, I must always use the same mirror. And what if it's unaccessible due to a server downtime? Yes, when downloading it will create the files under the mirror's filename. That's by design because different mirrors can have different views of what the latest packages are (and thus different setup.ini files and so on.) What I'm saying is that later on when you do the install from local dir step you should be able to continue to specify F:\CygwinInstall\ as the local package directory and it should automatically recursively scan the contents of all the different mirror dirs found under that directory and offer to install the union of all of them. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: CYGWIN=ntsec, cp -a, and NT acls
Rob Walker wrote: [RGW] Hm, looks simple... Why isn't this part of cp -a ? You have to understand the history of things. In the classic unix world, a file has an owner, a group, a mode, and several timestamps. From the standpoint of what cp -a can manipulate portably, that's basically it. All of those things are neatly returned by stat(3) and are easily settable/copyable across various filesystems. Extended attributes and/or ACLs are a relatively new introduction -- 'new' relative to the fact that traditional unix filesystems are more than 30 years old. They are also inherently very filesystem and operating system-specific: everybody does it slightly differently. Check out this overview of the subtle differences of a dozen different platforms' ACL APIs: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=doc/acl-resources.txt;hb=HEAD. It's very hard for a general program like 'cp' to know about all these various ACL APIs, let alone have any idea how it would go about translating the semantics of one to another, which would be required for copying across two different filesystems. Remember that 'cp' comes from GNU coreutils which is a set of generic tools that target dozens of various *nix-ish platforms, whereas the implementations of the getfacl and setfacl commands come from Cygwin itself which has the specific knowledge of Windows NT ACLs. [RGW] This differs from my experience. Many Windows tools are able to (built to?) twiddle +R and overwrite. They do not seem to be able to handle when the ACLs deny them permission, though. Again, attributes have zero to do with security or permissions. They are just a few extra advisory bits that the application (or C runtime) is free to interpret in any way it wants; they offer nothing in the form of OS-enforced restrictions. The Cygwin feature of using the 'backup privilege' to emulate root semantics is about bypassing ACLs, not attributes. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup.exe: all files in one common directory? (not per-server)
sowiso wrote: Yes, and that's another bad point about it! Different setup.ini files! What's the idea? A single setup.ini file describes a particular view of the state of the distro at a given point in time for a given site. Mirrors are inherently loosely synchronized on the order of hours, not seconds, and it would be insane to expect any higher level of coherency. You just have to accept that it's possible that for example a new package was just uploaded to the master site and that it might take 3 hours for it to reach mirror A and 6 hours for it to reach mirror B. If you hit mirror A and mirror B during that window there would be a discrepancy as to which version of that package was current. Thus, state must be maintained relative to each mirror, there is no such thing as global state. Why not one and the same setup.ini which can be read by _any_ mirror? There is exactly one master setup.ini on the sourceware site. But you cannot expect dozens of independent mirrors to always update in lock step. They will have their local view of what is current. That's exactly to prevent the left hand not knowing about what the right is doing or has done. Setup reads all the .ini files in the Local Package Directory and assembles the package state info from all of them to generate a view of what the latest available version of each package is. Nice, nice ... but sometimes I also *do* want to install manually without setup, e. g. sources. And always having to use Windows search or *nix find first which mirror the package has been assigned to this time is not really that cool. Well A) you can install source packages with setup.exe. And B) if you want a flat layout then mirror the files yourself using any method you want. You can use rsync for example to sync your local site to any of the rsync sites. You don't have to use setup.exe at all, and you can have your precious single setup.ini that way. (This is what I do personally.) Whatever method you use to get the files onto your drive is your own business, setup doesn't care. All it needs a dir with one or more setup.ini files. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Trouble differentiating Backspace from Control-Backspace in rxvt-20050409-9
Jonathon Merz wrote: I recently upgraded from rxvt-20050409-7 to rxvt-20050409-9 and have stopped getting different output for Backspace and Control-Backspace. In rxvt-20050409-7, I get ^? for Backspace and ^H for Control-Backspace. In rxvt-20050409-9, I get ^H for both. I've tried explicitly setting the rxvt backspacekey to ^?, but then I get ^? both with and without the Control key. I guess the first question is are you using rxvt in native (GDI/W11) or X11 mode. I can't see that much has changed in the patches other than tweaks to use the new modular X11 server. So if you are using GDI mode, then I'm at a loss to explain the differences, however if you are using X11 mode then it's highly likely that the difference in behavior is due to the many changes in the new X server and not anything in rxvt. You should follow up on the cygwin-xfree@ list if that is the case. I've also been trying to decipher some of the documentation for terminfo/termcap, though I'm having trouble wrapping my mind around those, and I'm not certain whether that is the path I should go down since my terminfo appears to be unchanged between the two. For what it's worth, I tried running infocmp on both the -7 and -9 versions and got identical output for them both. I think terminfo/termcap are irrelevant here as their purpose is to describe behavior, not to change it. They might document for example that terminal FOO generates the byte sequence BAR when the user presses key X so that programs can know that when TERM=FOO and the sequence BAR appears in the input stream that the user has in fact pressed X. But they can't alter the terminal's behavior to make it generate a different sequence. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
John Emmas wrote: In every case, the programs fail when the client attempts to connect to the server. This would be a typical line:- status = ::connect ( m_sock, ( sockaddr * ) addr, sizeof ( addr ) ); 'status' receives -1 and if I check the error it's invariably something like Connection refused (assume for the sake of argument that the supplied parameters are valid because the same programs work fine under Linux). The call fails because addr is junk, because the demo passed localhost to inet_pton. According to the docs, this function only takes IP addresses. If you change simple_client_main.cpp to use an IP address instead of localhost the example works for me. (It should really be modified to do a hostname lookup.) This example really isn't that great in that it's apparently relying on some non-standard behavior of glibc's inet_pton. Do I need to enable something in Cygwin for sockets to work? e.g. should I have previously run a service using cygrunsrv? I'm running out of things to try and there seems to be very little that could go wrong. I'd be grateful for any suggestions. Thanks No, you don't need to install any service to use regular sockets. The plethora of network tools in the distro (e.g. apache, curl, openssh, proftpd, lftp, wget, etc) that use sockets and that build without any special modifications should be an indication that this should just work. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Julio Emanuel wrote: 4) Only commands compiled for Cygwin, AND accessing the file system exclusively through the Cygwin POSIX interfaces can (and will) obey the chroot settings; This is not valid reasoning, as Eric Blake already pointed out you can still access files outside of a chroot even if you're still going through the Cygwin DLL by using Win32 style pathnames since Cygwin passes those through untouched. Whether or not you can trick the sftp code into letting such a filename through remains to be seen, but the point here is that just because the access occurs via the Cygwin API doesn't mean the chroot is absolute. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Julio Emanuel wrote: Aha! So this is the tiny bit that was missing! What you are saying is that the Cygwin DLL does not honor the chroot if the path is in WIN32 format? But why is that? It shouldn't honor the chroot all the time? I mean, this sounds like the right thing to do(tm), if Cygwin is supposed to fully support chroot environments... I haven't verified that this is the case, but I suspect that it is. The general philosophy of most of the path handling code is that Win32 paths bypass all Cygwin logic entirely. There are still lots of people that try to use Win32 paths with Cygwin tools despite the fact that it's not supposed to be how things are done (and discouraged.) As to whether it should try to special-case this situation and disallow the use of Win32 paths if a chroot is in effect, I'm not sure if it makes sense. As others in the thread have already said, the chroot feature is meant to be necessary but not sufficient, if you will. I.e. it's a convenience, not an enforecement. Most of the time when you encounter a program that's been put in a chroot jail the reasoning is so that if there is some kind of exploitable vulnerability in that program an attacker cannot gain access to the rest of the system outside of the jail. In this scenario the chroot provided by Cygwin provides zero protection, because if the attacker can run exploit code then can just call directly to the Win32 APIs and bypass Cygwin entirely. No amount of protection in the DLL will ever change this basic fact, so just seems to me like you'd be furthering the illusion of security by trying to add more checks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Socket programming with Cygwin
John Emmas wrote: Forgive me - but as someone who's very new to socket programming, I'm confused about why the program worked when I built it under Linux. Is it because something would have converted localhost to an IP address (is this the lookup stuff that you referred to?) and where can I find out a bit more about all this? Using the older/classic Berkeley API, the socket app calls gethostbyname() to convert a hostname to an address. The newer modern API is getaddrinfo() which has a slightly different interface and is more friendly for name lookups that could return IPv6 results. If you google sockets programming tutorial or the like I'm sure you can find some detailed guides. Keep in mind when reading these things that the native Windows socket API is Winsock, which is similar to the Berkeley socket API but has significant differences. One of the advantages of Cygwin is that you do *not* use the Winsock API, you use Berkeley/POSIX socket API, so don't try to use any Winsock tutorials or example code. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
TheO wrote: identifying what filenames are reserved by Win32, this is what I've got (please complete it if I am missing something): No, we mean get c:/dir/file or get c:\dir\file. (or put //hostname/share/file, shudder.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Finally managed to create a jailed SFTP server, but how secure?
Eric Blake wrote: That's with /. What about with \? The cygwin dll sometimes treats the two separators differently, where using \ is more likely to bypass cygwin checks. Don't forget the other variants, like \\.\c:\foo\bar \\./c:/foo/bar \??\c:\foo\bar \??/c:\foo\bar \??/c:/foo/bar Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: watch option processing broken
Daniel B. wrote: Similarly, if you try watch --interval=xx echo, you get no report that xx is not a valid number, or is not a valid interval value. It seems that option-parsing messages aren't getting printed out. I get the usage summary displayed as a result of that command, which is the normal behavior when an option can't be parsed. Apparently, the -d option code thinks -d takes an argument (taking the ls as that argument, leaving only dir as the apparent command to run(. Yes, it seems there is a getopt issue. But you can work around it by using the long form: watch --differences echo works OK. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: readline build questions
Eric Blake wrote:
I'm trying to resolve a bash bug caused by relying on auto-import rather
than __declspec(dllimport): http://cygwin.com/ml/cygwin/2008-11/msg00340.html
There is another potential workaround that doesn't involve modifying the
readline headers. If there are only a few places that compare function
pointers, then just compare against the _imp__FOO symbol directly.
extern char *_imp__rl_tab_insert;
...
if (function_returning_function_pointer () == _imp__rl_tab_insert)
{
/* function returned pointer to rl_tab_insert() in the DLL. */
}
This will however fail if you try to link bash against a static readline
because there will be no sythesized _imp__FOO symbol, causing link
failure. But here the breakage/restriction is limited to bash, rather
than being in the readline headers, i.e. it doesn't affect all readline
clients.
Is it still possible to allow clients to choose between static and dynamic
readline at link-time without supplying any compile-time flags, or does
the fact that I am conditionally using __declspec mean that I have to
adjust my conditions in readline.h, and that clients that want to link
statically now have to define READLINE_STATIC in their own source?
Unfortunately, yes. A call to a function explicitly declared dllimport
can only be satisfied by linking to a DLL containing that function, as
essentially the compiler has inlined the indirection of the thunk stub
into the call site. So the client of such a library needs an explicit
compile-time way of declaring intent to link statically, removing the
__declspec.
One other idea I had was to quit distributing a static libreadline.a, and
only offer the dynamic version. Does anyone see any problems with the
idea of no longer providing a static library?
You could make the argument that any consumers of libreadline in the
distro should already be using the shared version anyway on general
principle, so this shouldn't affect them. But then there could be
potential users that want to statically link it into their own
programs. I'd say continue to provide the static version, but just note
in the readme the new requirement to configure with
CPPFLAGS=-DREADLINE_STATIC if they intend to statically link. It's a
reasonable request given that it's not an uncommon idiom which is found
in other libraries, and it fixes a real bug. (What's more, if anyone
complains you can tell them that the alternative under consideration was
simple removal of the static version in We're Just Mean fashion.)
Brian
Re: Building for cygwin/win32 under Linux
Rich Simonis wrote: I don't know if I'm missing another include directive or a compiler switch, or just if my assumption that I can use the Linux g++ to cross-compile to Win32 is wrong. Your assumption is wrong. You need to build an actual cross-compiler (and cross-assembler, cross-linker), not just point a linux compiler at Cygwin headers. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [OT] Re: Opening a (cygwin-ised) DLL
Yaakov (Cygwin Ports) wrote:
John Emmas wrote:
Oops, I meant to ask another question (almost a variation on the same
theme). Does Cygwin itself (or more correctly, its linker) link
automatically to any of the standard Windows libs (such as kernel32.lib,
user32.lib etc).
kernel32 is added by default because libcygwin.a depends on it. If you
pass -mwindows to gcc during linking, then gdi32 is added as well.
It's not only kernel32:
$ gcc -dumpspecs | egrep -A2 '\*lib:'
*lib:
%{pg:-lgmon} %{!mno-cygwin:-lcygwin}
%{mno-cygwin:%{mthreads:-lmingwthrd} -lmingw32} %{mwindows:-lgdi32
-lcomdlg32} -luser32 -lkernel32 -ladvapi32 -lshell32
This means that by default -luser32 -lkernel32 -ladvapi32 -lshell32 are
added to every link, as well as -lgdi32 -lcomdlg32 if using -mwindows.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: help with bash/readline dll interaction bug
Eric Blake wrote: Is there some slick way to make bash grab a function pointer that can see through the trampoline and see that bash's trampoline version of rl_tab_insert is indeed the same function as readline's local rl_tab_insert? Sure, arrange for there to be a __declspec(dllimport) on rl_tab_insert's prototype when its header is used in bash (but not when it's used in building readline itself.) When you use explicit dllimport there's no need for the thunk and thus function pointers will compare as expected. The thunk stub is really a crutch that dates back eons ago to a time when support in compilers for DLLs was still new, as a way to let people link to DLLs with old compilers that didn't yet support the __declspec keyword. The fact that it is also handy for porting *nix code that doesn't traditionally use __declspec is a convenient coincidence. Would using gcc-4 have any impact on this? Not that I am aware of. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: XOrg 7.2 issue with -multiwindow
Uh Huh wrote: Yes, I read that more than once, and it appeared to contain nothing pertinent, other than the fact that compositing doesn't work with -multiwindow, and that there are plans to fix that later. Fine, Did you miss the following part? * The WindowsWM extension is currently disabled, as neither xwinwm nor the supporting code in the xserver currently build. This may be restored in a future release. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: libXaw8 replacement
Ken Brown wrote: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lresolv I assume this means that I have to install a package that contains the resolv library, but I couldn't find one by searching the cygwin package list. Can someone tell me what package I need to install? I've attached my cygcheck output so that you can see what I already have. You need to install the 'minires-devel' package. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: Cannot compile UUID module
Alexander Stadler wrote: So my next question is: Do you know what parameters are needed so that the Makefile will be created with the right settings (without manually executing g++ after the crashed first make)? Because creating it with: perl Makefile.PL LIBS=-L/usr/lib/e2fsprogs I would have tried LIBS='-L/usr/lib/e2fsprogs -luuid'. At the beginning I can even see: ... MakeMaker ARGV: (q[LIBS=-L/usr/lib/e2fsprogs]) ... # LIBS = [q[-luuid]] Note that this line is commented out. From past threads it seems that MakeMaker does not pass-thru -l arguments specified by the module author to the generated Makefile that it cannot find in the default library search directories. The fact that libuuid.a is in a non-default location (requiring an -L to locate it) on Cygwin seems to trip it up and cause -luuid to be omitted. But I would have suspected that with -L/usr/lib/e2fsprogs specified in a LDFLAGS override that MakeMaker would have added the directory to its list of search directories and let the option through. This is just speculation, having not tried it myself I don't know the real cause. Another commonly seen scenario is that the author of the module only tested it on systems where specifying the arguments with an incorrect order is tolerated. When this happens the Makefile itself can be incorrect with no way to fix it but patching it to use the right order. And by the way, in the PostgreSQL posts dllwrap was used with -Wl,-Bstatic,-luuid,-Bdynamic so when do I need the -Bstatic, -Bdynamic and should I use it too? Anything advocating the use of dllwrap should be highly suspect as old and inaccurate. It should not be needed in any modern workflow. -Bstatic is useful when you have both a shared and a static version of the same library and you want to prefer the static version, since the default is to prefer the shared. That is why you see it used in pairs, switching to static for one -l option and then back to shared so that no options found later on the command line are affected. On Cygwin this means if you had both an import library libuuid.dll.a and a static library libuuid.a, you would need to use -Wl,-Bstatic to make the linker use the static version when resolving -luuid instead of the import library. However, in this case again the advice is highly suspect because there is no shared version of the uuid library in the e2fsprogs package, only a static one, so specifying -Bstatic is extraneous and useless. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot compile UUID module
Alexander Stadler wrote: gcc -c -DPERL_USE_SAFE_PUTENV -U__STRICT_ANSI__ -fno-strict-aliasing -pipe -I/ usr/local/include -DUSEIMPORTLIB -O3 -DVERSION=\0.02\ -DXS_VERSION=\0.02\ -I/usr/lib/perl5/5.10/i686-cygwin/CORE UUID.c rm -f blib/arch/auto/UUID/UUID.dll g++ --shared -Wl,--enable-auto-import -Wl,--export-all-symbols -Wl,--stack,838 8608 -Wl,--enable-auto-image-base -L/usr/local/lib -L/usr/lib/e2fsprogs -Wl,-Bst atic -luuid -Wl,-Bdynamic UUID.o -o blib/arch/auto/UUID/UUID.dll \ /usr/lib/perl5/5.10/i686-cygwin/CORE/libperl.dll.a\ UUID.o:UUID.c:(.text+0xe): undefined reference to `_uuid_generate' The ordering here is wrong. -luuid must come after UUID.o on the command line if the linker is to resolve uuid_* symbols in UUID.o from the -luuid library. With standard autoconf this is achieved by the convention that -l arguments must go in LIBS not LDFLAGS. I don't know if the perl system uses the same convention, but whatever it uses, the -luuid argument does not belong where it's currently being set. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ITA] X.Org X11R7.4
Yaakov (Cygwin Ports) wrote: libXfixes3 and libXfixes-devel have category: X11 and external-source: libXfixes. AFAIK (and please correct me if I'm wrong) upset and/or setup require a binary libXfixes package to go alongside the source package, so they are empty. I don't want the empty binary libXfixes to pollute the package list, so I used the _source category for libXfixes so that it's hidden by default. I don't like the precedent this creates -- it's bad UI. The user is supposed to be able to get the source by just putting an X in the Src box of the normal package. But with this scheme they can no longer do that, they have to know to first show hidden packages and then to select the Src column of an empty dummy package that is otherwise never displayed, used, or needed. Why can't you just associate the source package with one of the two existing binary packages instead of inventing a third, empty, hidden package to associate it with? Brian
Re: [ITA] X.Org X11R7.4
Brian Dessent wrote: I don't like the precedent this creates -- it's bad UI. The user is supposed to be able to get the source by just putting an X in the Src box of the normal package. But with this scheme they can no longer do that, they have to know to first show hidden packages and then to select the Src column of an empty dummy package that is otherwise never displayed, used, or needed. Errr, nevermind. That's nonsense. Setup will follow the external-source line and do the right thing when the user selects Src of any of the packages. Why can't you just associate the source package with one of the two existing binary packages instead of inventing a third, empty, hidden package to associate it with? But I still think this makes more sense. Brian
Re: [ITA] X.Org X11R7.4
Yaakov (Cygwin Ports) wrote: Because this means jumping through a lot more hoops, believe me. This method (where there's no binary package corresponding to the source package) has precedence in Debian as well. If it really does save you time than I remove my objection. Can I just request that the sdesc of such packages say something informative and explicit about their purpose, e.g.: sdesc: X.Org Xfixes library (dummy placeholder for source package) I realize this string will never be seen by end-users but it does help to self-document the purpose behind the package's existance when one is troubleshooting setup by looking at setup.ini or whatnot. Brian
Re: Call undocumented NTDLL functions with Cygwin/gcc?
David Arnstein wrote: #include w32api/ddk/ntapi.h You don't need the w32api prefix, that is part of the built-in search path -- otherwise, #include windows.h would not work. You also need to link with -lntdll. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]
Charles Wilson wrote: Well, if we continue -- at present -- with static libstdc++, then would we need to continue -- at present -- with static libgcc even for C libraries? For example: cygncurses-N.dll : if this C library is compiled using -shared-libgcc then cygncurses++-N.dll : this C++ library can't be linked (right?) It's C++, but depends on cygncurses-N.dll. From what I understand, you have to have static libgcc and static libstdc++, or shared libgcc and shared libstdc++, you can't mix them. And because you can't link against cygncurses-N.dll (which was linked against the shared libgcc) without specifying -shared-libgcc when linking your client...boom. Or, am I wrong on that (I'd love to wrong about that) -- if so, then you CAN do what would effectively be -shared-libgcc -static-libstdc++? I'm not aware of anything that would preclude mixing static libstdc++ and shared libgcc. It needs some testing, obviously. updated gcc-4.3). Version bump the C++ libraries again. However, if one of the issues is the versioning of the libgcc shared library, then the C libraries will ALSO have to be rebuilt again -- but they may (or may not) have to be version bumped again at that time. They probably will. Clients from scenario 2/phase 1 expect the old cyggcc_s.dll -- which was fine with cygncurses-N.dll which also used cyggcc_s.dll. However, this new cygncurses-N.dll depends on cyggcc_s-2.dll so now the client will pick up two different runtime support libraries: cyggcc_s.dll directly, and cyggcc_s-2.dll via cygncurses-N.dll. That's bad. So, even the C libraries will need the second version bump, for scenario 2/phase 2. Yes, this is why having an unversioned but shared libgcc in the distro is such a poison. With the current state of gcc4 it's impossible to win as maintainer of a C++ library: if you use the default options you get static libgcc which means your library can't throw or catch exceptions from other modules. If you use -shared-libgcc you get a dependence on an unversioned shared lib which makes the output unsuitable to be released to the public in the distro because it will only cause headaches later. So I consider this gcc4 package to be in a preview state, but it its output should not be considered suitable for packaging yet. Brian
Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]
Charles Wilson wrote: Err...but that's a good description of cygwin-1.7, as well. Nobody (as far as I am aware) is suggesting that a test/preview gcc-4.3 package should be used as a regular compiler for cygwin-1.5. I thought so as well, but people are already putting stuff built with gcc4 into the distro: http://cygwin.com/ml/cygwin-announce/2008-09/msg00017.html. The question is, do we take a flyer on gcc-4.3 in the cygwin-1.7 sandbox, hoping to get /all/ the kinks worked out -- in both gcc-4.3 and in cygwin-1.7 -- by the time cygwin-1.7 goes gold. I guess all I'm saying is that the minimum precondition before we should even think about starting to recompile anything is that gcc4 should default to shared and versioned libgcc. Until then it's just going to create more headaches to deal with later. Brian
Re: gcc-4.3 compatibility and cygwin-1.7 policy questions [Was:: Re: SECURITY vulnerabilities update 2007-Sep-25]
Charles Wilson wrote: Or is all the worry about about unwinding a C++ only issue? (And of As far as I can tell, it is. Note that gcc doesn't[1] emit any unwind tables for C language input, even on platforms like Linux that have been DW2 for a long time. So if you somehow managed to get yourself into a situation where you were throwing from a C++ frame and the unwinder encountered a C frame, it would call terminate() there too -- that would be undefined behavior. But even if the unwinding differences (sjlj vs dwarf2) are NOT an issue for C libraries, will there be incompatibilities between C client apps that use static 3.4.5 libgcc.a and my C DLLs that use (static? shared?) 4.3 libgcc? Aside from the EH issue, I don't think that there would be any problem. Here is a list of all the functions exported by libgcc.a and libgcc_eh.a. With the obvious exception of the EH ones and possibly the tlsemu ones, I don't see any that would carry any inherent state information such that they would get confused by one caller getting the static version and another the one from a libgcc DLL. Exception handling support: _Unwind_Backtrace _Unwind_DeleteException _Unwind_Find_FDE _Unwind_FindEnclosingFunction _Unwind_ForcedUnwind _Unwind_GetCFA _Unwind_GetDataRelBase _Unwind_GetGR _Unwind_GetIP _Unwind_GetIPInfo _Unwind_GetLanguageSpecificData _Unwind_GetRegionStart _Unwind_GetTextRelBase _Unwind_RaiseException _Unwind_Resume _Unwind_Resume_or_Rethrow _Unwind_SetGR _Unwind_SetIP __frame_state_for __gcc_personality_v0 __deregister_frame __deregister_frame_info __deregister_frame_info_bases __register_frame __register_frame_info __register_frame_info_bases __register_frame_info_table __register_frame_info_table_bases __register_frame_table Threading support: These should all map onto the respective pthreads API functions in the Cygwin DLL, so they shouldn't themselves have any state. __gnat_default_lock __gnat_default_unlock __gnat_install_locks __gthread_active_p __gthread_mutex_lock __gthread_mutex_unlock TLS support: These might carry some shared state and require -shared-libgcc. However, since this did not exist prior to 4.3 there's no backwards compatibility issue either. __emutls_get_address __emutls_register_common The rest are mostly arithmetic, which shouldn't maintain any state: DI mode (64 bit long long) arithmetic: __muldi3 __negdi2 __lshrdi3 __ashldi3 __ashrdi3 __cmpdi2 __ucmpdi2 __divdi3 __moddi3 __udivdi3 __umoddi3 __udivmoddi4 __udiv_w_sdiv Trapping arithmetic: __absvsi2 __absvdi2 __addvsi3 __addvdi3 __subvsi3 __subvdi3 __mulvsi3 __mulvdi3 __negvsi2 __negvdi2 Bit operations: __ffssi2 __ffsdi2 __clzsi2 __clzdi2 __ctzsi2 __ctzdi2 __popcountsi2 __popcountdi2 __paritysi2 __paritydi2 __bswapsi2 __bswapdi2 Float to an integer power: __powisf2 __powidf2 __powixf2 Complex mode arithmetic: __mulsc3 __muldc3 __mulxc3 __divsc3 __divdc3 __divxc3 integer-float conversions: __fixsfdi __fixdfdi __fixxfdi __fixunssfsi __fixunsdfsi __fixunsxfsi __fixunssfdi __fixunsdfdi __fixunsxfdi __floatdisf __floatdidf __floatdixf __floatundisf __floatundidf __floatundixf Misc: _alloca __chkstk __clear_cache __enable_execute_stack __eprintf __gcc_bcmp IMHO, shared libgcc needs to be the default and all C++ libraries (and applications that link to C++ libraries) will need to be rebuilt to use it. But at the moment this is a problem because: a) gcc-4 still defaults to static libgcc, requiring -shared-libgcc flag to link with the DLL b) libgcc DLL is named just cyggcc_s.dll, but it should be versioned c) the shared gcc runtime package is currently named just gcc4-runtime, but it should be both versioned and split into individual components, i.e. we should have libgcc0, libstdc++6, libgfortran0, and so on, however: d) shared libstdc++ doesn't exist yet because of the operator new/delete overriding issue. At the moment it looks like our best option is to leave static libstdc++ the default but have a shared option available for code that doesn't need to override operator new/delete, until (d) is fixed at which point we make shared the default. Ideally for future sanity I think we need to get away from all these static copies of the runtimes being default and make everything use DLLs, but I understand that's not practical right now. Brian [1] Well, it does if you specifically ask for it with -fexceptions or -fasynchronous-unwind-tables. But AFAIK there are no C libraries in the Cygwin distro built this way.
Re: bash: Word splitting but when?
[EMAIL PROTECTED] wrote: the ouput of $(echo '1 2 3 x') should go through word splitting and x Word splitting does not occur in the right-hand side of an assignment. From the manual: A variable may be assigned to by a statement of the form name=[value] If value is not given, the variable is assigned the null string. All values undergo tilde expansion, parameter and variable expan- sion, command substitution, arithmetic expansion, and quote removal (see EXPANSION below). If the variable has its integer attribute set, then value is evaluated as an arithmetic expres- sion even if the $((...)) expansion is not used (see Arithmetic Expansion below). Word splitting is not performed, with the exception of $@ as explained below under Special Parameters. Pathname expansion is not performed. Assignment statements may also appear as arguments to the alias, declare, typeset, export, readonly, and local builtin commands. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [perl] Portably linking to libstdc++
Sisyphus wrote:
Of course, the other option on both linux and cygwin is to set *both*
$Config{cc} and $Config{ld} to 'g++', and that works fine on linux, but
doesn't quite work on cygwin where I still get an undefined reference to
[EMAIL PROTECTED]':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../libcygwin.a(libcmain.o):(.text+0xab):
undefined reference to [EMAIL PROTECTED]'
collect2: ld returned 1 exit status
Why does that happen ?
The error means you tried to link an executable that didn't contain a
main() function. The fact that it refers to a missing WinMain() is
incidental, a byproduct of some compatibility code in Cygwin that
provides a backup main() which calls WinMain(), allowing the
Windows-style tradition where the user provides a WinMain() instead of
main(). Regardless of how it's spelled, you can't link an executable
without a proper entrypoint which is all the error means.
Please post the entire link command and not just the error. It's
impossible to say what the true nature of the problem is otherwise. For
example, if you're trying to link a library and not an executable then
the above error would be due to missing the -shared flag.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: problem compile with gcc
bjoe wrote: The thing that confusing me is the error came from w32api packages, not from source code. Maybe someone in this list can explain to me about what going on here. You haven't provided enough information, such as what version of w32api you're using. If you aren't using the latest (3.12-1), first upgrade and see if the issue is fixed. If that doesn't help then we need to see the code, or a standalone testcase that reproduces the problem. It could be an #include problem, for example #including a header that is not meant to be included directly -- the MSDN page for each API function tells you which header to include to use that function. And many windows headers require windows.h to be included first. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [perl] Portably linking to libstdc++
Sisyphus wrote: Apparently g++ needs a -shared but ld2 doesn't. (I don't understand that.) And I don't understand what is achieved by: gcc -shared -o Size.dll -Wl,--out-implib=libSize.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--stack,8388608 -Wl,--enable-auto-image-base \ -s -L/usr/local/lib Size.o /usr/lib/perl5/5.8/cygwin/CORE/libperl.dll.a That command gets run only if LD is ld2 - there doesn't seem to be a comparable command if LD is set to either g++ or g++ -shared. /usr/bin/ld2 is a wrapper script that calls /usr/bin/perlld which is another wrapper script that adds all those extra parameters if it detects that a library is being linked. So yet another workaround would be to edit perlld and change my $CC = 'gcc' to g++. Maybe you should try the current perl 5.10 where all these crufty wrapper scripts are gone and it should work without any hacks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compile time Local Cygwin vs. VMware session on same system
Manning, Sid wrote: I was surprised to see that I could compile much faster under VMware than on Cygwin on the same host. Why is that surprising? Cygwin and VMware work on entirely different principles. Plus your chosen benchmark essentially tests the two slowest aspects of Cygwin, process creation and filesystem access, both of which are particularly fast on Linux. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [perl] Portably linking to libstdc++
Sisyphus wrote:
But on cygwin, there is no '-lstdc++' to be found in $Config{libpth}, so
MakeMaker decides to not pass the switch on (which has always been
MakeMaker's policy in such cases, afaik). This is a pity - there would be no
problem if it *did* the pass switch on, as both gcc and g++ on cygwin will
resolve that link.
MakeMaker should be fixed to allow the switch through.
Really the correct way to link C++ code is by using g++ which doesn't
require this manual -lstdc++ nonsense. Can't you just do that, by
either fixing the makefile to link with $(CXX) or overriding the
appropriate variable?
Or, how about:
$ perl Makefile.PL LIBS=$(${CC:-gcc} -print-file-name=libstdc++.a)
But this is still not optimal because it assumes static libstdc++, which
has been the only available choice until now but will not be in the
future, i.e. we want to move to shared libstdc++ eventually with gcc4.
The optimal solution again is to link by calling $(CXX) and not have to
worry about any of this.
IMO, on my cygwin perl, $Config{libpth} should be set to '/usr/local/lib
/usr/lib /lib /lib/gcc/i686-pc-cygwin/3.4.4', and I regard it as a bug that
'/lib/gcc/i686-pc-cygwin/3.4.4' is not being included in $Config{libpth}. In
fact, I've modified the libpth setting in Config.pm to '/usr/local/lib
/usr/lib /lib /lib/gcc/i686-pc-cygwin/3.4.4'.
$libexec/gcc/$target/$version is a private directory of the compiler.
The compiler knows how to find it, and other external apps should not
need to know what it is or even that it exists. Exposing this internal
detail of the compiler to any other build system is just plain wrong for
many reasons.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: cygwin:g++linker problems
jayshankar nair wrote: The libraries is build with gcc(in cygwin environment). Something to do with flags or packages. Shared libraries have the extension .dll on Windows, not .so. Specifying -lf will find your library if you named it cygf.dll or libf.dll, or if you created an import library libf.dll.a. (It will find other variants as well, like f.lib. Read the linker manual for the full list.) If you want to name a DLL with a nonstandard extension like .so there is nothing stopping you, but you can't expect the -l switch to find it if you do. You can specify it to the linker by filename directly though. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: how install ifort in cygwin ???
meyus wrote: I try to install the compilator ifort in cygwin but i have this message : Error etc... don't find 'ldd' ??? It sounds like you're trying to run an install script for Linux binaries. That's never going to work, primarily because there is no 'ldd' command in Cygwin, but even if there was[1] it wouldn't matter as Cygwin can't run Linux binaries anyway. Cygwin emulates Linux at the source level, not the binary level. If you want to use the Intel Fortran compiler with Cygwin you must use the Windows version, which is probably not what you want to hear because the Windows version is not free. If you want a modern and free Fortran compiler that works with Cygwin you should use gfortran. Brian [1] Yes, cygcheck can do something similar to ldd but that's not relevant here. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Setup 2.573.2.3 says GDB 6.8-2 but installs 6.8-0
Thomas Nilsson wrote: In fact, the package is named gdb-6.8-2.tar.bz2 but when untar'ed displays binaries from 6.8.0. The final number after the dash is the revision number of the packaging, not part of the program's version number, so you should interpret 6.8-2 as the second incarnation of the 6.8 package, and it indeed does contain gdb 6.8. Brian
Re: Linker Search Directories
John Emmas wrote: I'm trying to build a project (using make) that needs python. Python's link library is in /lib/python2.5/config/ but unfortunately, 'make' doesn't seem to be aware of this and fails with the message:- make doesn't know anything about linker search directories. It just executes commands that are listed in the Makefile, it has no knowledge of their semantics. So the answer depends on how the Makefile was written. In projects that use autoconf, you can define variables when you run configure, e.g. ./configure LDFLAGS=-L/usr/lib/python2.5/config --enable-foo --with-bar ... If there is no configure script you can still override variables when invoking make, but it becomes less obvious what the correct values are since you have to look at the Makefile to find out what the variable currently contains so that you can know what to set it to. For example, if the final value of LDFLAGS in the Makefile after everything is substituted works out to -lfoo -lbar -lpython2.5, then you would override it to add the necessary flag, e.g. make LDFLAGS=-lfoo -lbar -L/usr/lib/python2.5/config -lpython2.5 This is a pain, it's much simpler with the autoconf method because the starting value of LDFLAGS is empty and autoconf adds on things to the user's setting. With make overrides you have to include the full final value with your addition added on, which can be nontrivial to figure out as you have to read through the whole Makefile. And in the autoconf world anyway the configure script is supposed to do the job of determining all of this automatically -- both of which are reasons why shipping a bare Makefile without a configure script is not very portable and unfriendly. I also note that this is supposed to be covered by the python-config script, such that autoconf scripts or Makefiles can query the set of required flags to be added to LDFLAGS/LIBS/CPPFLAGS/etc by the output of python-config. However it seems the Cygwin packaging of python is broken because A) the python-config shebang points to a bogus #!/tmp/python.6884/usr/bin/python2.5.exe, and B) it doesn't include the necessary -L anyway. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Linker Search Directories
John Emmas wrote: I'm about to build another library called liblo. This library uses various functions with names like getaddrinfo(), freeaddrinfo() etc (all of which are declared in /usr/include/gettaddrinfo.h). On my Linux box, these functions reside in 'libc.a' - but in Cygwin, they're in a different library, called 'libgetaddrinfo.a'. Once again, this isn't currently know to liblo's build scripts. Uh, what? getaddrinfo() is implemented in Cygwin itself, which is the equivalent of -lc and is implicitly included in every link, so you should need no such external library at all. The library is in a standard directory, so to include it, do I simply type:- ./configure LDFLAGS=-lgetaddrinfo The proper variable for -l flags is LIBS not LDFLAGS. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Circular dependency problem
John Emmas wrote: functions contained in the other one). If I was programming in Microsoft VC++ I'd normally resolve this by exporting the relevant functions. Exporting them (I believe) tells the linker that any unresolved function addresses will be resolved at run time (hence, dynamic linking). That's not how DLLs work. All references must be defined at link time, there is no way to defer them to runtime unless you explicitly use LoadLibrary/GetProcAddress and function pointers. __declspec(dllexport) does not change the situation at all. What you probably meant was that you (or perhaps the IDE did it for you) created a .def file which lists the exported functions of a DLL before it actually exists, which can be used to create an import library for linking. I don't know how the equivalent technology works in gcc but whatever it involves, the project compiles and links fine on my Linux box. However, I can't make it build with Cygwin. Both branches compile successfully but neither will link because the other one hasn't been built yet. Is there anywhere where I can find some information about how to make this work? I could probably make a cut-down version if anyone wants to see the problem for themselves. Create a .def file listing the exported functions of library A, and then generate an import library from that. Link library B against the library A import lib and at the same time create an import library for B. Then link library A against that. $ dlltool -d libA.def -l libA.dll.a $ gcc -shared $libB_objects -o libB.dll -L. -lA \ -Wl,--out-implib,libB.dll.a $ gcc -shared $libA_objects -o libA.dll -L. -lB Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Linker Search Directories
John Emmas wrote: Initially, that's what I thought too Brian. They're part of libc when I compile under Linux but they're not there for Cygwin (and I only installed Cygwin a few weeks ago). I need to link to libgetaddrinfo. In fact I searched libc to find the function names but they aren't there. Sorry, I've been using 1.7 for so long that I forget what's in 1.5. It's been in 1.7 since 2006-07-06 but was never backported to 1.5. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Can anyone help please, with syntax ?
John Emmas wrote: When I got to the 'make install' stage for fftw3 it installed its files under /usr/ whereas my other libraries seem to be installed under /lib/ (e.g. fftw3f.pc was in /usr/lib/pkgconfig/ - whereas 'everything_else.pc' seems to be in /lib/pkgconfig/). I'm assuming that this might cause future problems if I need to build and install libraries manually. Should I be doing something to circumvent this? /usr/lib and /lib are the same directory. http://cygwin.com/faq/faq-nochunks.html#faq.using.directory-structure Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cygwin bash
John Emmas wrote: When I double click the 'Cygwin' icon on my Windows desktop, a DOS-like window opens which I'm led to believe is Cygwin's bash terminal. However, with every version of Linux that I've used, the bash terminal had menus allowing me to do certain things like (for example) copying pasting text. Cygwin's terminal window is more like a DOS one with no menus and very limited copy paste features. Is that correct or has something gone wrong with my installation? What you are seeing is a Windows console. It's provided by the operating system for any executable that was marked as a console mode app. It is not bash-specific and indeed bash (and cygwin1.dll) have zero control over how it behaves or operates. If you want something with more sophistication you need to use a different terminal, such as rxvt, xterm, cygputty, poderosa, or console. But the default Windows console does not require installing an X11 server or any other external software which is why it's the default. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gs.exe missing from ghostscript package?
Lee D.Rothstein wrote: 'gs.exe' the Ghostscript interpreter is missing from my configuration. That's because there is not supposed to be a gs.exe. The ghostscript packages use the alternatives facility, which means /usr/bin/gs is a symlink to /etc/alternatives/gs which is a symlink to either /usr/bin/gs-x11.exe or /usr/bin/gs-native.exe depending on how you've configured your system. Either way, it should work to execute 'gs', though. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: gs.exe missing from ghostscript package?
Lee D. Rothstein wrote: What causes the link to have its extension exposed and become inoperable within Cygwin? Even after I did a complete reinstall. I've seen this before. Does it have to do with the permissions? For shortcut-style links, the .lnk file needs the readonly attribute to be treated as a symlink. attrib +R gs.lnk ought to fix it. But it would be good to find out why its attributes got munged in the first place. BTB, I first did a search on cygwin.com for the package containing gs, and it said that there was such a file in the ghostscript package, not ghostscript-base. The older 8.50 version of the package had a gs.exe before it was converted to use the alternatives system, which is the hit you are seeing when you do a search. But you have 8.62 installed which contains gs-native.exe. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin-make issue
Clearcase Administrator wrote: Any ideas ? Do I need to upgrade mae ? cygwin ? I want to use the parallel make option of make. You need to re-read the replies that you already received. The error is not from make, it's from the KJxSvc program (whatever that is -- it's not part of Cygwin) which is not capable of dealing with files being in use by other parallel jobs. This has nothing to do with either Cygwin or make. It is possible to modify your Makefile to cope with non-parallel safe programs, such as by using order-only prerequisites and sentinal files. However, that is not Cygwin-specific and you'd be better off asking on the make list. (And you'd have to provide much more detail than what you've given for anyone to be able to suggest workarounds.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [OT] polite response to rather rude reponse...
Barry Smith at SourceLink wrote: Stop spreading FUD. There is no way a userland app like run.exe can cause a blue screen. Only something running in kernel space -- like windows core code, or certain device drivers -- can ever do that. Then I guess you don't read the cygwin archives, because that's where I read the entire thread while I was researching RUN/START execution under cygwin. That doesn't mean that 'run' was at fault. If a user-mode program results in a BSOD that means it exercised a bug in a kernel-mode driver, such as a faulty virus scanner or other security type crapware. There is simply no way that a user-mode program can cause a BSOD on its own. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [OT] polite response to polite response - Brian...
Barry Smith at SourceLink wrote: That doesn't mean that 'run' was at fault. Yet it could have been at fault, or the cygwin memory allocation could be at fault, or Windoze, or the tool that you're RUN-ing. The Cygwin memory allocation most certainly could not be at fault, nor could the tool being run. Again, the one and only thing that is culpable when a BSOD occurs is code running in kernel mode. Any attempt from user-space to do anything untoward simply results in a software fault, with a default handler installed by the OS which terminates the process if it does not handle the fault itself. Thus the very worst a process can ever do is get itself terminated. Anything more is simply not possible, as enforced by the processor which is running in protected mode. That's not to say that a BSOD cannot result from the action of running user-space code, but when it does the underlying reason for the BSOD cannot possibly be in the user-space code, it must be a bug in kernel-mode code because by definition it is charged with disallowing any process from destabilizing the system, and it has failed. (And please, it's spelled Cygwin, not CygWIN.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: I could not still install octave-3.0.2-2 by setup.exe
Tatsuro MATSUOKA wrote: Apparantly cygwin setup went well, however no component of octave-3.0.2-2 is installed. I cannot indicate what is wrong. As it says in the announcement this release is marked Experimental. When using setup.exe you will never have experimental/test versions installed unless you ask for them explicitly by selecting the Exp radio button. Brian
Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
Dave Korn wrote:
Yep, that's more-or-less what I was referring to by stunk thubbery ;-)
With one important difference: the plan you outlined relies on the .exe
exporting the function that overrides the copy in the dll. This is
somewhat controversial (IMHO) in that it requires adorning the function
with __declspec(dllexport) (or -Wl,--export-all-symbols or using a .def
file) and it is not typical to export from an executable. If at all
possible I'd like to avoid this.
The current special casing for malloc/free doesn't require exporting,
because the names of the overriding symbols are available to the linker
at the time the executable is linked (i.e. the statically linked crt
startup code), and so it can choose at that time which copy to resolve.
The problem with this is that, contrary to what I outlined previously,
it cannot be done dynamically; the linker must see a reference to the
symbol, i.e. foo = malloc;. But this can be solved as you hinted by
adding a static stub to the import library. The issue about breaking
direct-to-DLL linking is not a problem in my opinion, because in the
Cygwin distro we always use import libraries because they provide the
ABI name indirection that lets e.g. -lintl link to cygintl-8.dll
without having to specify it as -lintl-8. There are other situations
where an import library is required, such as when you are trying to link
to stdcall calling convention functions that aren't decorated. So this
would just be another case where using an import library is required,
and it would be of essentially zero burden to the distro as it exists
today because we always ship and import lib anyway.
So, we teach the linker that when creating an import library for a DLL,
if it sees a weak function exported it should emit a small static stub
in the import library that takes the address of that function. We can
add a runtime support function to receive that address, let's call it
_pei386_add_overridable() just for the sake of argument. It could be a
static CRT function like the runtime pseudo reloc helper function
_pei386_runtime_relocator() which also gets statically linked into every
app, or it could be in libgcc, or Cygwin. I'd prefer the static CRT
option, just because it is universal, standalone, and safe; and there's
a precedent for doing it that way with the runtime pseudo reloc helper.
The downside of this is that it will require apps to be linked with a
newer (presumbaly 1.7 only) version of Cygwin to pick up the new
libcygwin.a which contains these static bits.
Anyway, so the linker puts a stub that looks like this in the import
library of the DLL it is linking:
_pei386_weakhelper_uniquestring()
{
_pei386_add_overridable (malloc, malloc);
}
Where malloc is the symbol that was marked weak in the DLL it's
linking. The uniquestring is just something to make sure no two of
these collide but is also unique in that it can be keyed to the function
name. Maybe it's just the function name alone, I dunno.
Next we need something to cause these stubs to get included into the
link when linking an executable against such an import library. So we
make the linker keep a running tab of symbols in the executable that it
has resolved with an import library for which there exists a
_pei386_weakhelper_uniquestring() stub for that symbol. At the end of
the link it synthesizes a function that calls each of the stubs, and
adds that synthetic object into the link:
_pei386_weakhelper()
{
_pei386_weakhelper_for_sym1();
_pei386_weakhelper_for_sym2();
...
}
Next we add a call to _pei386_weakhelper() in the Cygwin CRT startup so
that that synthetic object and all stubs get pulled into the final
link. We also write an implementation of _pei386_add_overridable() that
just maintains a list of pairs of (function name, pointer).
At this point we have achieved the feat that we have at runtime a
dynamic list of all overridable functions by name and pointer, without
ever touching the export tables or requiring they be exported at all.
The other half of this version of the plan would be identical to yours,
i.e. add indirection on the DLL side to get the function's address at
runtime. Preferably this would be in a sort of PLT-like manner where
the overhead of looking up a symbol's address by name only happens the
first time and thereafter it's just an indirect jump through a slot.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
Dave Korn wrote: Why bother? Hence the may. I don't plan to bother for myself, but it depends if I Please don't. gcc isn't special in this regard, it shouldn't receive any special treatment. bash fails without cygintl-8.dll and I don't think anyone is proposing to statically link libintl into bash just because some people seem to find ways to screw up their installations by not installing libintl8. If there's a problem we need to fix the root cause, not paper it over. Besides, in 1.7 there is a sensible error message when a DLL isn't found. That's all I get from a default build, I'm not sure if --disable-libjava is the upstream default right now but knowing the somewhat sorry state of libjava on cygwin I wouldn't be surprised. (I'll give it a go and if anything manages to compile, I'll ship it.) You do need --enable-libjava on Cygwin, it's not enabled by default. Aaron posted a patch to build is as a DLL and with that it should be usable again, at least with DW2 (not SJLJ.) The bulk of the issues as I understand it were with the fact that statically linking java just doesn't work very well. The problem with making shared libstdc - it can be done - is that it shows regressions, because win32 doesn't currently fully support the semantics of weak symbols like ELF does. Specifically, since a DLL has to be fully-resolved when it is linked, any references to e.g. operators new/delete get statically resolved as internal calls within the DLL, and then when you attempt to define a custom operator new/delete override within your executable, it doesn't get interposed between the already-resolved calls and their destinations within the DLL. This would make the C++ compiler non-compliant, so as it all works OK with a static library, I'm shipping it that way for now. IMHO, despite the above we should still ship shared libstdc++ even if it's not the default -- though I would even argue that we should go one step farther and make it the default and say that if you need to override operator new you select the static libstdc++. Otherwise, we just get ourselves into ABI compatibility hell because every C++ library gets a copy of libstdc++ linked into it, which means they are tied to the compiler version. As it is now we are going to have to rebuild all libstdc++-using code in the distro with the new compiler because up until now we had no choice but static libstdc++, but by not stopping this insanity now we only prolong it. I plan to work on improving weak symbol support in binutils to resolve this problem in the long run; I think we can make it work with a little bit of thunk stubbery[*]. PE does have weakref, where you supply a backup symbol name along with the reference. If the symbol is defined elsewhere then that definition is used, otherwise the backup one supplied with the weakref is used -- but in either case it does not go undefined. But I'm not sure how this would be useful in the case outlined above. Also, is OpenMP available? Is it being worked on? ? dunno. That's a whole nother story, isn't it? Should work fine. Requires explicit --enable-libgomp though (not enabled by default.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
Dave Korn wrote: If they were instead resolved to some kind of thunk that could do a lookup at runtime for non-weak versions of the same symbol, we'd be golden. Well, we'd need to make sure the non-weak versions were all declspecced dllexport somehow, but that would do it for us. Well we already have this problem with the Cygwin DLL and standard malloc(). It's solved in lib/_cygwin_crt0_common.cc:_cygwin_crt0_common(). This code gets statically linked into every executable, which means when it takes the address of malloc and free that address will bind to the user's overrided function if present, otherwise it will import it from the DLL. I think we can extend this for operator new and delete. The only issue is the addresses are stored in an internal Cygwin data structure (struct per_process) which will not be accessible from within libstdc++. You could add helper functions that retrieve them, but that seems like additional overhead. You could also just store them in variables that are exported by the DLL. Then you'd just need something in libstdc++ that wraps all calls to new/delete through the addresses imported from those variables. Or, how about this: you could just have the Cygwin DLL export the wrapper functions as themselves, i.e. with the proper mangled names. Then building libstdc++ as a DLL would always bind new/delete to those wrappers with no extra modification to the libstdc++ sources. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New experimental package: gcc4-4.3.0-1
Christopher Faylor wrote: sys_sigabbrev is not in cygwin.def. There are several variables which are not exported via cygwin.def. Hmm... I'm surprised that works. Shouldn't the def file contain the complete list? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: upgrading to perl-5.8.8-4
Rob wrote: 1. Why is /usr/lib/perl5/site_perl not listed on 5.8.8 ? Because having an unversioned directory in @INC was a mistake that was corrected. 2. why are there duplicate entries for: /usr/lib/perl5/site_perl/5.8 /usr/lib/perl5/vendor_perl/5.8 vendor_perl contains modules that ship with perl from the packager. site_perl contains modules that were locally installed from CPAN. 3. Even though /usr/lib/perl5/site_perl/5.8/cygwin and /usr/lib/perl5/site_perl/5.8 are listed in @INC, the /lib/perl5/site_perl directory does not get created when the package is installed and is missing. Then it sounds like you've not installed anything from CPAN. It should be created and populated the first time you do that. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe --quiet-mode
Dave Korn wrote: Err, that should never happen, unless you're updating from a several-years-old DLL. The Cygwin DLL is intended to be backwardly compatible, and only rarely have their been ABI breaks. So this aspect of updating doesn't get tested very often. No, that's wrong. It is expected to see errors about missing entry points, because what's happening is a binary that was built against a newer cygwin DLL is being run against an older cygwin DLL because it could not be replaced. The backwards compatibility only works in the other direction, where you run an older binary against a newer DLL. There is no workaround for this. You either make sure the DLL isn't in use or you suffer from broken postinstalls (which usually means a broken installation.) There's really nothing else that can be done. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe --quiet-mode
Christopher Faylor wrote: Dave did suggest a possible workaround - delay any postinstall scripts until the next reboot. That's more graceful than requiring the user to re-run setup to catch the failed postinstalls. But it still results in a broken system until the next reboot since those binaries that were just installed will all fail if you try to run them. (And if they don't fail because of missing entry points, they could fail because their postinstalls were deferred.) That's what I mean by no workaround -- the immediate result after running setup with cygwin1.dll in use is a broken system, and there's not a lot you can do to avoid that other than don't run setup with important DLLs in use. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] New experimental package: gcc4-4.3.0-1
René Berber wrote: --enable-shared-libgcc --enable-__cxa_atexit --with-gnu-ld --with-gnu-as Err, that's not good. Cygwin does not support the __cxa_atexit extension, that's only a feature of glibc. This option should not be be used on libcs that don't provide the feature. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New experimental package: gcc4-4.3.0-1
Christopher Faylor wrote: I haven't tried this with the actual released compiler yet but, assuming it works the same way, mm I wrong or is there something wrong with this compiler? The code it creates seems to be correct (and Cygwin is noticeably smaller) but I'd like to get rid of all of the new warnings. I can't get rid of this one because I don't see how to do that. The warning is correct, technically. When compiling strsig.cc, you want the variable to be exported, not imported. When compiling everything else that includes signal.h, you want it to be imported. There are actually two things wrong here, as I see it: one, dllexport should not be necessary at all as the exports are controlled by the .def file. Two, you only want the dllimport attribute to be present when signal.h is included by clients, i.e. outside of Cygwin, so the __declspec should be turned off #if defined(__INSIDE_CYGWIN__). Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Is there a limitation I don't know about in setup.exe dependency checking?
Dave Korn wrote: want to trace the dependency? That is to say, is it not allowed/intended to satisfy a missing dependency with a test version? I think it tries to satisfy the dependency with whatever the current global trust level is set to. So if the radio button is on Curr but there's no Curr version available, it won't do anything. But if the radio button is Exp then it should be able to add in Exp versions. (I'd have to dig into the code to see whether this is truly the case or whether it's just hardcoded to Curr only. I think that's a bug if true.) Now admittedly this is really stupid logic. It should try to match the trust level of whatever was just selected when adding dependent packages. Brian
Re: MinGW runtime and w32api
Chris Sutcliffe wrote: My question is, should I use the same naming convention for the Cygwin distribution, or keep things the status quo? That doesn't conform to the Cygwin standards, so I'd say no. If you wanted to split up mingw-runtime into separate DLL and header packages, they should be named something like libmingw and libmingw-devel. But seeing as how the only file that would be in libmingw is mingm10.dll (and that's just a tiny stub that hardly ever changes), this seems like real overkill. w32api should likewise theoretically be named w32api-devel but I also don't see any need to rename something gratuitously. Brian
Re: Difficulty building gcc 4.3.2 under i386-pc-cygwin
Werner Wothke wrote: $ make [ -f stage_final ] || echo stage3 stage_final make[1]: Entering directory `/cygdrive/c/gcc-4.3.2/Destination' -bubble'. Stop.rule to make target `stage3 make[1]: Leaving directory `/cygdrive/c/gcc-4.3.2/Destination' make: *** [all] Error 2 The overlapped nature of the error would indicate that you have spurious CR characters in a file somewhere. With a complicated build system like gcc there's no way that's ever going to work, and in general using Cygwin with DOS line endings is a recipe for doom and frustration. Use a binary mount and don't use Win32 tar extractors that do helpful line ending convesions (e.g. WinZip.) Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Cannot change file permission with either chmod or setfacl
Laurent Monnoye wrote: $ chmod 600 foo $ ls -l foo -rw-r--r-- 0 xotrader01 Users 4 Sep 5 18:05 foo You've left out the most relevant detail: what type of filesystem does foo reside on? NTFS, FAT, NFS, Samba? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: setup.exe --quiet-mode
Rob wrote: until you click the OK button. This clearly is not unattended. It would be better if it could just exit with a specific error code that you could read and take some action (restart). I agree that it's not correct, but I disagree about the conclusion. It should silently schedule any inuse files for replacement on the next reboot, and continue. Bailing in the middle of the process of unpacking files is going to leave a horribly broken system: only some packages that were selected are unpacked, others are not; and no postinstalls were run. You could have missing DLLs, things not installed properly, etc. At least if you schedule for replacement you can continue unpacking everything else, and so the possible scenarios for a broken system are much narrower and rarer. Moreover if the user doesn't know to check the exit status, they will have no idea of the level of brokenness. I also want to point out that unattended installs are meant for people that know what they're doing, they are not meant for casual users. In fact it's not even a officially supported mode of installation -- if it works for you great, but it's not a primary feature. Thus we're way off in the woods here, in that running an unattended install and also not closing all apps is kind of combining two already sketchy things. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: file attributes: cygwin (ls, chmod, chown, chgrp) versus XP
Michael R. Wolf wrote:
Where can I get a simple (and current) description of the relationship
between Unix file attributes (permissions, user, and group) and how that
corresponds to XP file attributes?
The Cygwin Users Guide: http://cygwin.com/cygwin-ug-net/ntsec.html.
The section labeled 'The mapping leak' gives an explicit example of how
a POSIX mode gets mapped to a set of NT ACLs.
I'd also like to know how to set/get them in cygwin and also XP. I'd expect
that to be chmod(1), chown(1), chgrp(1), id(1), ls(1), passwd(5), group(5),
and the shell's file test operators (-r, -w, -x, -O, -G).
Those tools only set the traditional unix style ownership and
permissions. The Windows security model is more expressive, so you can
also use {get,set}facl to access the extended permissions that don't fit
into the traditional user/group/everyone bins.
I only see a few attributes from the XP File Explorer (read-only, hidden,
archive, system), but would expect much more.
You're looking at the wrong thing. Those aren't ACLs, they're just file
attributes. Are you by any chance using Windows XP Home? That version
of Windows hides file ACLs from the user interface, but they still exist
on disk. To see the ACLs in Explorer, right click on the file, select
Properties, then select the Security tab. This is still a watered down
view of the ACLs, to see the full view click on the Advanced button.
You should see a list of ACLs, such as Administrators - Full Control,
Users - Read Execute and so on. cacls and xcacls also display
ACLs.
I've noticed that the ls(1) output is different if I create a file with a
cygwin utility or with an XP utility. Specifically:
1. What does the + mean in the 11th column after the standard 1-column type
and 9-column permission fields?
This is explained in the documentation for ls:
$ info coreutils ls 2/dev/null | grep -A4 'extended access control
list'
For a file with an extended access control list, a `+' character is
listed. Basic access control lists are equivalent to the
permissions listed, and are not considered an alternate access
method.
Remember that for GNU projects the man page is considered a summary
only, and the full documentation is in texinfo. The '+' essentially
means that there are ACLs that cannot be mapped into the traditional
unix user/group/everyone r/w/x bins. You can see them with getfacl.
2. Why are default permissions different if the file is created with cygwin
and XP? I understand that cywing will try to create them with 666, modulated
by the umask of 0022, yeilding a default of 644, but how the heck does XP
come up with 700+ (my interpretation of rwx--+)?
POSIX/Cygwin programs create files with an explicit mode, as dictated by
the umask.
Windows programs do not traditionally care about ACLs, and they tend to
specify a default value to the file APIs which means they inherit a set
of ACLs from their container, which in the case of a file is its
directory. You can see this in the Explorer UI as there is a column
labeled Inherited From. And likewise if that directory was created by
a Windows program it probably inherited its default ACLs from its parent
directory, going all the way back to the root drive which had its
default ACLs set when the filesystem was created.
This is of course a generalization, as inheritance is optional (you can
see the checkmark in the Explorer UI labeled Inherit from parent )
and Windows programs can create files using any arbitrary set of ACLs if
they desire. The behavior is thus program-specific, but you can
generalize: the vast majority don't care and specify a default value
which causes them to be inherited.
In addition, I can't get group information to show up in ls(1) output. The
-G flag to suppress it has no effect, and seems to always be active.
You have to set up your groups file correctly if you want to see
symbolic group names instead of numeric ones.
It seems like these would be an important topics to reference in the ls(1)
and chmod(1) man pages, and also in the (seemingly outdated) documentation of
File Permissions (http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-files).
It's not outdated unless you're using 1.7, which has its own version of
the Users Guide.
Have there been significatnt changes to cygwin since NT to accomodate XP? I
don't even know if the NT and XP filesystems are similar enough that I can
rely on documentation that discusses NT vs cygwin.
NT is a generic term, meaning any version of Windows that's not
95/98/ME. When the users guide talks about NT permissions it means
NT/2K/XP/2k3/Vista/2K8.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: undefined section `.gnu_debuglink' referenced in expression
carlos wrote: /oss/src/winsup/cygwin/cygwin.sc:143: undefined section `.gnu_debuglink' referenced in expression That's due to a change in binutils that caused it to be more strict. The offending line has been removed from the linker script in HEAD. You can either make the appropriate change in the branch, or downgrade binutils. I'd recommend the former. See http://www.cygwin.com/ml/cygwin/2008-06/threads.html#00014 and http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/cygwin.sc.diff?r1=1.22r2=1.23cvsroot=src. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: why the strange stack stuf in cygwin?
[ Your messages would be a lot easier to read without the random
schizophrenic line length and indentation. ]
Jay wrote:
I meant implementing __thread in gcc.
Starting in 4.3 gcc supports emutls, which enables __thread support on
all threaded targets, even when there is no actual TLS support. It does
this by mapping accesses to the gthread API in libgcc, i.e.
__gthread_{get,set}specific. This is a generic API that maps onto one
of several platform specific thread APIs. In the case of Cygwin this is
pthreads, i.e. Cygwin defaults to --enable-threads=posix. This means
the accesses will go through pthread_{get,set}specific().
Obviously this is not usable from inside Cygwin, but otherwise it should
work fine.
they are of release quality (last I checked), and they aren't upstream I
think.
That's not true. The x86_64 MinGW target is fully functional in FSF gcc
and binutils. I don't know if it can bootstrap itself yet or is still
limited to crosses, but it's at the point where the output is usable at
least.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Import library for symbols decl. without dllimport
John E. / TDM wrote: This of course works fine, but it's sub-optimal; I would like for the message not to be displayed at all, and I imagine that the auto-import machinery shouldn't even need to be activated if the import library for the libstdc++ DLL is properly designed. Also, hiding the message with --enable-auto-import would also hide similar messages from other libraries that I *would* want to see. That's just not how it works for data imports. For functions yes, but not for data imports. You either use auto-import or you __declspec(dllimport). It works for functions because the call can go through a thunk stub. But for data variables not marked __declspec(dllimport), there's no indirection; the only way to add the required indirection (to make the reference to a symbol in another module whose address isn't known until runtime) is to trick the operating system loader into modifying the text section at runtime which is what auto-import does. There's no way to simulate this with just an import library as is possible with function thunks. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [ITA] apr1-1.3.3-1
David Rothenberger wrote: I've changed the package structure as follows: ~ * libapr1: Runtime library and documentation. ~ * libapr1-devel: Development headers and libraries. ~ * apr1: Source package. Something seems wrong here. At the moment for the ABI=1 version we have: @ apr1 sdesc: The Apache Portable Runtime (development/documentation package) category: Libs Devel requires: cygwin libapr1 @ libapr1 sdesc: The Apache Portable Runtime (runtime package) category: Libs requires: cygwin Okay, so you want to rename apr1 to apr1-devel, that makes some sense. But why does apr1 continue to contain just the source? Why not just have apr1-devel contain the source and make apr1 a completely empty package? I don't think category _obsolete should contain any packages that contain current versions, it should either be older ABI versions (awaiting remaining clients to be rebuilt) or empty dummy packages to support renaming/splitting. Does this also mean that you will take over these as well: @ aprutil1 sdesc: Additional utility library for use with the Apache Portable Runtime (development/documentation package) category: Libs Devel requires: cygwin libaprutil1 apr1 libdb4.2-devel libgdbm-devel @ libaprutil1 sdesc: Additional utility library for use with the Apache Portable Runtime (runtime package) category: Libs requires: cygwin libapr1 libexpat0 libiconv2 libdb4.2 libgdbm4 crypt Also, there are these four old ABI=0 packages to deal with: @ apr sdesc: The Apache Portable Runtime (development/documentation package) category: _obsolete requires: cygwin libapr0 @ libapr0 sdesc: The Apache Portable Runtime (runtime package) category: _obsolete requires: cygwin @ apr-util sdesc: Additional utility library for use with the Apache Portable Runtime (development/documentation package) category: _obsolete requires: cygwin libaprutil0 apr @ libaprutil0 sdesc: Additional utility library for use with the Apache Portable Runtime (runtime package) category: _obsolete requires: cygwin libapr0 expat libiconv2 libdb4.2 libgdbm4 crypt I can't find anything in current setup.ini that actually requires these ABI=0 versions (other than themselves) so can't we just delete the above four outright? Or, how about the following idea: repurpose the the package named apr (which was previously the ABI=0 one) to be the main documentation and source package for the current ABI=1, so that we'd have: @ apr sdesc: The Apache Portable Runtime category: Libs requires: libapr1 libapr1-devel @ apr1 sdesc: Empty placeholder category: _obsolete requires: libapr1 @ libapr1 sdesc: The Apache Portable Runtime (runtime) category: Libs external-source: apr requires: cygwin @ libapr1-devel sdesc: The Apache Portable Runtime (headers) category: Libs Devel external-source: apr requires: libapr1 Brian
Re: rsync in cygwin
Edward Blum wrote: The scenario is: Ubuntu machine running rsnapshot ssh's into remote machine running cygwin 2.6.9 on windows 2003 and uses rsync to backup the files. The error I get is: There is no such version of Cygwin. You are referring to the version of rsync. Reading up is it to do with a limitation of windows being 255 maximum character set is there any way round this? If you've searched the archives then surely you have also read that Cygwin 1.7.x supports a PATH_MAX of 4096, so the workaround is to wait until 1.7 is released. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: rsync in cygwin
Edward Blum wrote: Thanks for your swift reply! I see there are release candidates flying about for 1.7 reckon they would be stable enough to try them out or would I be better waiting for a stable release? Is there some where I can find the release cycle? I don't know whether you could call 1.7 stable or not. We'll only know if people test it. Do note that it's meant to be coupled with an upgrade helper script in the base-cygwin package that transitions your mount table from the registry into fstab, so if you just plop down a 1.7 version of the DLL on top of a 1.5 installation without taking any further steps you will probably have a semi-working system, as /usr/bin won't be able to be found and so on. For this reason you're better off using the 1.7 setup which does support installing in a separate independent tree (for the time being during the testing period at least) so that your 1.5 tree remains untouched. All of the details and caveats are hashed out in various cygwin-apps@ list threads, so you'll want to consult the archives. Moreover, in addition to simply running the 1.7 DLL you'd likely need to rebuild rsync against the 1.7 headers in order to take advantage of the change in PATH_MAX. I don't know if such a 1.7 rsync binary package has been made available in the release-2/ tree or not, but I suspect it hasn't, which means you'd have to take care of this yourself as well. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: [Avail for test] login-1.9-8
Gary Wernsing wrote: I added the SetIncreaseQuotaPrivilege to the cyg_server user and that cured the problem. [For those who got here on a search, this is found as Local Computer Policy\ Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ User Rights Assignment\ Adjust memory quotas for a process when using the gpedit.msc group policy edit snap-in] Alternatively: $ editrights -u cyg_server -a SeIncreaseQuotaPrivilege Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Text Mode and $'\r': command not found error
Clément LABORIE wrote:
source ${PROJECT_DIR}/myBash.bash
. $'\r': command not found
echo ${PROJECT_DIR}
E:/project/...
When I replace ${PROJECT_DIR} by Unix directory /cygdrive/e/project/...,
it works well.
What version of bash are you using? Have you read point 6 in
/usr/share/doc/Cygwin/bash-*.README? Have you considered using cygpath
to automatically rewrite the Win32 paths?
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Probably stupid make question
Phil Smith wrote: We're perverting CMake and Cygwin make to use a cross-compiler for z/OS (IBM mainframe). We've beaten it mostly into submission, but are hitting an issue with definitions being passed. Cygwin make seems to be passing them in the format: -Dvarname value rather than: -Dvarname=value and the cross-compiler doesn't like that much. Some discussion with more *IX-savvy friends suggests that the blank format is older, and is deprecated due to ambiguity (does -Dvarname abc.c xyz.c mean set varname to abc.c and compile xyz.c, or set varname to 1 and compile abc.c and xyz.c?). I think you're going to have to be more specific, such as providing a testcase that reproduces the problem. This must be due to some aspect of cmake, because there's nothing in plain make (AFAIK) that has anything to do with how -D or any other parameter is passed to any tool -- make executes commands exactly as written in the Makefile, no more no less. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: man: cygwin 1.7.0 and special filename chars
Yaakov (Cygwin Ports) wrote: Am I missing something here? Apparently my understanding of FAT is wrong then. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Updated: perl-ExtUtils-Depends-0.300-2
Reini Urban wrote: Sure. Fixing libtool of course. Mixing static and dynamic libs should be possible. I think you're missing the point of why libtool disallows it: not because it won't work in a specific instance, but because it is not portable. There is no fix for the fact that on some systems it's impossible to link a shared library that contains non-PIC code, and that on those same systems static libraries are built non-PIC. The core idea behind libtool is to abstract away these sort of details, so if it made an exception and allowed this to succeed on some systems but refused on those systems where it's impossible then it would fail to meet this most basic goal. In other words: there's nothing to fix. Why can't the libWin32CORE library just be shared? Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: man: cygwin 1.7.0 and special filename chars
Yaakov (Cygwin Ports) wrote: It's not a case of using the same workaround. With 1.5, the make manifypods target would first build the PODs, then create the manpages, and would fail when trying to create a manpage containing '::' (as it did not use a managed mount). gtk2-perl.cygclass would then catch the error, and then proceed to use a similar procedure to generate the manpages with a '.' instead. With 1.7, there is no such issue; make manifypods builds OOTB. So any such workaround would have to be caught in the cygport postinstall stage, maybe in __prepman(). But I'm not sure that it would be at all necessary. Oh. I see. That's unfortunate. But I don't understand something: I'm looking at the documentation for ExtUtils::MM_Cygwin which claims to contain platform-specific overrides for ExtUtils::MakeMaker, one of which is replace_manpage_separator that is documented as: replaces strings '::' with '.' in MAN*POD man page names It seems like this issue has already been considered and solved upstream. Why does this not kick in? Really? I thought that was the rule for case-sensitivity, not illegal chars: http://cygwin.com/ml/cygwin-apps/2008-08/msg00079.html Well yes, case-sensitivity also has similar set of restrictions. But the support for illegal chars is implemented by mapping them into a Unicode private use area. FAT is codepage-based and doesn't support Unicode so I don't see how this could work. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: New Setup for Cygwin 1.7 on cygwin.com
Corinna Vinschen wrote: No, it hasn't. I already removed this dependency a week ago. Perhaps something wonky with unionfs is happening then because I clearly see it in the setup-2.ini on sourceware at this moment: [EMAIL PROTECTED] ~/ftp]$ awk '/^@ base-cygwin$/,/^requires:/' setup-2.ini @ base-cygwin sdesc: Upgrade helper scripts from 1.5.x to 1.7.x ldesc: Upgrade helper scripts from 1.5.x to 1.7.x category: Base requires: bash coreutils Brian
Re: [RFC] 1.7 Packaging: Obsolete packages
Corinna Vinschen wrote:
Ok, I'll have a look. Any idea about my other question? How to remove
the entire installed.db package DB when the user goes back to the root
dir selection dialog so we can reload from another location, should the
user choose one?
My aborted unfinished attempt at a 1.7 setup also suffered from this.
The plan of attack that I had was to move the code that reads
installed.db out of the packagedb ctor and into its own private or
static function. Then write a new member function that first frees the
in-memory copy (if it exists) and then calls that reader function. Then
hook this function into the wizard dialog so that it's called every time
you move off the rootpage.
As far as the actual freeing of memory, I think it would go something
like
for (vector packagemeta *::iterator i = packages.begin ();
i != packages.end (); ++i)
{
delete *i;
}
packages.clear();
(And likewise for sourcePackages.) Yes, it royally sucks that setup has
this horrific mix of containers as well as explicit pointer management.
Ideally it would be great to eliminate all explicit new/delete
housekeeping and instead make them smart pointers, but that's a big
project.
Is that really a big point? The replaces stuff is meant to seemlessly
replace one package with (usually) a functionally at least equivalent
package. There shouldn't be much of a difference for the user.
You mean is it not a big point that the uninstallation of the packages
listed in Replaces: wouldn't be indicated anywhre? Yes, I suppose
it's somewhat of a minor point. But I really do think that setup has
enough odd and inexplicable behavior already that I hesitate to add more
-- being able to always double check the precise set of
install/remove/upgrade operations that are about to take place with the
Partial view is a useful debugging tool.
OTOH, a replaces rule does not allow to replace an obsolete package
automatically. So, if we want to upgrade the user automatically to the
new packages, we would *still* have to provide empty obsolete packages
with a setup.hint requiring the new packages.
What would the replaces rule buy us again?
I don't know. Maybe what is needed is a key that works in the other
direction, Replaced-by: with the semantics of: if this package is
currently installed then de-install it and install everything in the
specified list. So to rename/split a package you would upload the new
package(s) under the new name(s), move the old package to category
_obsolete (so that it's not shown) and add a Replaced-by: newname
line. This would cause a silent upgrade for everyone the next time they
ran setup, the same way that bumping the version and uploading an empty
file does today.
Off the top of my head, complication with this idea:
- the Replaced-by would have to be transitive in the dependency
computation code as well. So if a maintainer renames package OLDNAME to
NEWNAME, then a package that requires: OLDNAME would have to have
OLDNAME replaced with NEWNAME in the internal representation of the
dependency list. It's tempting to say that the maintainer should just
add NEWNAME to the requires: of OLDNAME, and let the requirement
chain. But I don't think that would fly because what we're saying with
this keyword is that OLDNAME won't be installed any more. This is in
opposition to the current method where OLDNAME does actually stay
installed (in the mind of setup) but contains an empty payload so has no
footprint.
- the Replaced-by method would not allow a determined user to continue
using an old version of a package without upgrading. With the current
scheme they can just mark the existing package as Keep (or select a
Prev version) which has the effect of blocking the upgrade since it
works on the principle of the bumped version triggering the action. But
with a Replaced-by keyword doing the action instead of the presence of a
bumped version, there would be no choice.
Brian
Re: New Setup for Cygwin 1.7 on cygwin.com
Corinna Vinschen wrote: Why didn't upset pick up the change? Perhaps it has to do with the design of upset being incremental, i.e. taking the current setup-2.ini as input and applying updates to it rather than generating it from whole each time. It might be confused upon not seeing a requires: at all in the .hint and so it leaves the existing requires: in the .ini unchanged. If this is the case then listing an explicit empty requires: in the .hint would probably work around it. If true then it sounds like more of a bug to fix than something we want to kludge around. Brian
Re: [RFC] 1.7 Packaging: Obsolete packages
Brian Dessent wrote: - the Replaced-by would have to be transitive in the dependency computation code as well. So if a maintainer renames package OLDNAME to And, as a corollary to that: Replaced-by should accept only a single packagename as predicate, since we have this requirement of replacing any occurance of OLDNAME with NEWNAME in the internal dependency database. I suppose it could in theory take a list of multiple packages but then we'd have to deal with replacing one thing with multiple things and that just seems overly complicated. If a one-to-many relationship is required it can be achieved by setting the requires: of NEWNAME to pull in the extra ones. Brian
Re: [RFC] 1.7 Packaging: Obsolete packages
Brian Dessent wrote: - the Replaced-by method would not allow a determined user to continue using an old version of a package without upgrading. With the current scheme they can just mark the existing package as Keep (or select a Prev version) which has the effect of blocking the upgrade since it works on the principle of the bumped version triggering the action. But with a Replaced-by keyword doing the action instead of the presence of a bumped version, there would be no choice. And thinking about this some more, we could work around that issue by implementing the treatment of the Replaced-by keyword as-if the user had manually deselected OLDNAME and selected NEWNAME. Thus if they select Keep then that action is undone and the list of operations is cleared as expected, and all packages stay at what they're set to now. Of course we'd need to hook it into the right places so that these as-if selections are not just done once but every time that the trust level is set to Curr. Otherwise, you'd miss the upgrade if you clicked on Keep then clicked again on Curr (or Exp for that matter.) So to sum up an implementation skeleton: - add the keyword to the lexer and parser - add an additional packagedb data member that contains a vector of OLDNAME-NEWNAME pairs found from the result of parsing the ini file - add code that runs after reading the installed.db that changes any occurance of OLDNAME to NEWNAME in any package's dependency spec - add code in the set global trustval codepath that runs after all the exising calculations to set the transitions as-if the user had deselected OLDNAME and selected NEWNAME for each pair, recomputing full recursive dependencies each time -- but *only* if setting the trustval to curr or exp, not keep. Brian
Re: [RFC] 1.7 Packaging: Obsolete packages
Corinna Vinschen wrote: IMHO, the replaced-by would add nothing in terms of less maintainence burden. The old package still has to be tweaked in one way or another. The only extra work without replaced-by is to create empty tar archives for the old packages, which is really simple. As I do not maintain a huge number of packages I really can't comment on what maintainers need or want. Certainly we shouldn't waste time designing something that's not going to be helpful. But I do seem to recall that Yaakov stated early in this thread that some kind of help with renaming/splitting packages would save a great deal of work for him, so perhaps we should wait for him or someone else with tons of packages to comment. Brian
Re: [RFC] 1.7 Packaging: Obsolete packages
Corinna Vinschen wrote: Something's obviously missing... Yes, I led you astray, sorry. That is going to purge absolutely everything that setup knows about packages. In order to get that back it would be necessary to re-parse setup.ini and re-scan the local package directory for its contents to see what's available. What's needed is rather than nuking the database, to undo the information about what versions are currently installed. This is rather dicey because each packagemeta contains a std::set of packageversions, each of which could have come from setup.ini, or from the parsing of the filename in installed.db. So we can't just remove everything from that set. But if you don't remove anything you'd leak (or end up with duplicates, or end up with nonsense versions) because the code in the installed.db reader (below) creates a new packageversion unconditionally. Really what we want to do is undo this: packageversion binary = cygpackage::createInstance (pkgname, inst, instsz, f.ver, package_installed, package_binary); pkg-add_version (binary); pkg-set_installed (binary); pkg-desired = pkg-installed; I think what might be required is to add another field to packageversion to denote whether it came from reading setup.ini or from reading installed.db. (Remember that it's possible that the installed version is not Curr nor Prev nor Exp, it could be anything.) Then add a method to packagemeta that removes from 'versions' any that came from installed.db, leaving the ones that came from setup.ini. (This will need an operator delete to balance the operator new in cygpackage::createInstance otherwise it leaks.) Then we can call that method on each packagemeta in the packagedb::packages vector. We'll also need to set the 'desired' and 'installed' members to point to something sensible, because otherwise they are potentially dangling if they pointed to something we removed. I'm not sure what that something is, but to find out you can put some debugging statements in and find out what everything looks like after parsing setup.ini and scanning the local package dir but prior to reading installed.db to find out how to reverse the changes. Brian
Re: [ANNOUNCEMENT] Updated: cygutils-1.2.7-1
Sam Kuper wrote:
1) Was the rename utility removed from cygutils at some point between
version 1.2.6-1 and 1.3.2-1, or is my version of cygutils somehow
corrupt?
2) If it was removed, why, and is there some other way I can obtain
the rename utility under cygwin? (NB. please don't just suggest I use
for i in *; do mv ${i} ${i#foo}; done, etc. - I'm asking
specifically for the rename *utility*, not a rename capability.)
Everything is in the announcements. It was moved out of cygutils in
1.3.0 and into util-linux:
http://cygwin.com/ml/cygwin-announce/2006-04/msg3.html
http://cygwin.com/ml/cygwin-announce/2006-04/msg9.html
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: [ANNOUNCEMENT] Updated: cygutils-1.2.7-1
Brian Dessent wrote: Everything is in the announcements. It was moved out of cygutils in 1.3.0 and into util-linux: And, additionally, next time try: $ cygcheck -p rename.exe Found 3 matches for rename.exe. util-linux/util-linux-2.12r-2 Random collection of Linux utilities util-linux/util-linux-2.13.1-1 Random collection of Linux utilities util-linux/util-linux-2.13.1-2 Random collection of Linux utilities Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Compiling gcc for cygwin
NightStrike wrote: If cygwin ever wants to be able to support newer gcc compilers, something needs to be done in this area. There are several options, That's a quite a misleading statement to make. Everything is fine for a native 4.4 using 3.4 as the bootstrap compiler. That's the whole point of the three stage bootstrap, to eliminate any influence of the bootstrap compiler on the final compiler. The problem only occurs when you build a 4.4 cross using 3.4 because by definition you can't bootstrap a cross. But even then you're fine if you first bootstrap a recent native to use to build the cross. It's really not the end of the world. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: man: cygwin 1.7.0 and special filename chars
Yaakov (Cygwin Ports) wrote: 1) Completely remove the /::/./ substitution in both man and perl for 1.7; 2) Have man look for both '.' and '::'. How about 3) Perpetuate the s/::/./ workaround in Cygport so that manpages continue to be generated with '.'. Rationale: Support for : in filenames in 1.7 only works with local NTFS and remote NFS drives; local non-NTFS and remote samba volumes will fail. For example, if recent list traffic is any indication, running Cygwin off a portable Flash drive is becoming a popular topic again with the /etc/fstab change, and most of those devices are formatted FAT. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
