Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-10
On 6/17/2009 10:10 PM, Christopher Faylor wrote: On Wed, Jun 17, 2009 at 07:22:33PM -0600, Eric Blake wrote: According to Ken Brown on 6/17/2009 7:07 PM: On 6/17/2009 6:22 PM, Jon TURNEY wrote: Sorry for not mentioning this before you did the packaging, but can I suggest that emacs-X11 package setup.hint should have font-adobe-dpi75 and font-misc-misc added to the requires: line Good idea. Can someone just do that now, or does it have to wait for the next update? I've done it for now; but you'll have to remember to update your setup.hint for the next update. Thanks for doing this Eric. Thanks from me too, Eric. I noticed that you also added cygwin to the requires: line of emacs-X11, even though emacs-X11 requires emacs which requires cygwin. Is this just a precaution in case setup.exe messes up the dependencies, or is there some deeper reason? (BTW, I see that you also added cygwin to emacs-el, but it isn't actually needed. In fact, I'm just realizing that emacs-el doesn't even need to require emacs.) Ken
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-10
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ken Brown on 6/18/2009 2:09 PM: Thanks from me too, Eric. I noticed that you also added cygwin to the requires: line of emacs-X11, even though emacs-X11 requires emacs which requires cygwin. Is this just a precaution in case setup.exe messes up the dependencies, or is there some deeper reason? All packages get cygwin added automatically by the upset script before creating the final setup.ini for public consumption. I did not add it at the setup.hint level. This script also adds the _postinstall dependency for any package with .info files. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko67skACgkQ84KuGfSFAYAKTgCgq4czMvzwyfgiiBoSDai21Zyw pb0Anijz39V1R1oudDRiOhEa7oYWhrKM =bomA -END PGP SIGNATURE-
Re: [RFU 1.7] {emacs,emacs-X11,emacs-el}-23.0.92-10
On Thu, Jun 18, 2009 at 07:50:01PM -0600, Eric Blake wrote: According to Ken Brown on 6/18/2009 2:09 PM: Thanks from me too, Eric. I noticed that you also added cygwin to the requires: line of emacs-X11, even though emacs-X11 requires emacs which requires cygwin. Is this just a precaution in case setup.exe messes up the dependencies, or is there some deeper reason? All packages get cygwin added automatically by the upset script before creating the final setup.ini for public consumption. I did not add it at the setup.hint level. This script also adds the _postinstall dependency for any package with .info files. And yet, no matter what I do, the cygwin's and _update-info-dir's still keep creeping back into the setup.hint files. cgf
Re: Proposed patch to system.XWinrc
On 6/17/2009 3:17 PM, Jon TURNEY wrote:
+ emacs execbash -l -c /usr/bin/emacs
notepad execnotepad
xload execxload -display %display% # Comment
}
The most important part of this is changing the way emacs is called;
the original version didn't work at all for me (i.e., emacs didn't
start). This might be related to the fact that I've installed the
emacs-23 packages, which use the alternatives system:
/usr/bin/emacs - /etc/alternatives/emacs
/etc/alternatives/emacs - /usr/bin/emacs-X11.exe
The command lines for menu items are just supplied to execl('/bin/sh -c
...') after a fork, so it should have no problem following symlinks, and
a bare emacs works for me (I tested 23.0.92 under Cygwin 1.7)
It turns out that I was using a modified startxwin.bat that didn't set
up the path correctly. So now it works for me too. Nevertheless, I
prefer bash -l -c /usr/bin/emacs so that the bash initialization files
are processed before emacs starts. For various reasons, I want the
environment inside emacs to be the same as the usual bash environment.
I suspect that most emacs users would want that, but I don't really know.
Ken
--
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/
Myron Stiles?
Hi Myron, Maybe you're who I'm looking for... We have a new product and system that some of our top earners are using to bring in over $2,500 per WEEK. We're looking for a dreamer, someone who can see themselves earning that kind of money. ...but wants to do it from home, part time. Would that be you Myron? If so, go register here, so I know you're interested. http://www.sprinklelife.com/cgi-bin/arp3/arp3-t.pl?l=1c=1624792 My site will present the details, but hurry, this is limited. http://www.sprinklelife.com/cgi-bin/arp3/arp3-t.pl?l=1c=1624792 Regards, Brian Your Subscription Details: Name: Myron Stiles Email: cygwin-xfree@cygwin.com Phone: IP Address: 199.229.208.73 To be removed see below: *-1823*Heikkala*Drive* *-Marquette*MI* *-49855 US* If you wish to cancel your subscription, simply click once on the link below. http://www.sprinklelife.com/cgi-bin/arp3/arp3-un.pl?c=1624792p=913c97 -- 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: Blank title bars
From: cygwin-xfree-ow...@cygwin.com [mailto:cygwin-xfree-ow...@cygwin.com] On Behalf Of Csaba Raduly Sent: Wednesday, June 17, 2009 2:19 AM For some reason, changes to the title bar text result in a blank title bar instead until the window loses focus. [SNIP/] According to the About box, the X server is version 1.5.3 (20090222) Cygwin1.DLL 1005.25.0.0 (1.5.25-cr-0x5f1) Has anybody seen anything like this? Any ideas? I'm running 1.5.3 (20090225) on XP, and have no such problem (don't know how to get the cygwin DLL version). Are you perchance running Vista? Best bet is to upgrade to the latest and see if the problem persists (you've tried rebooting, yes?). HTH, Mike -- 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: ioctl(sock, SIOCGIFHWADDR, ifr) fails with 1.7
Am 15.06.2009, 11:22 Uhr, schrieb Frédéric Bron frederic.b...@m4x.org:
To fix your application, call either
struct ifconf ifc;
ifc.ifc_len = sizeof (struct ifreq) * 32;
ifc.ifc_buf = malloc (ifc.ifc_len);
if (ioctl (fd, SIOCGIFCONF, ifc))
/* Resize ifc_buf and retry */
else
{
struct ifreq *ifr = ifc.ifc_req;
struct ifreq ifr2;
for (int i = 0; i ifc.ifc_len; i += sizeof (struct ifreq), ++ifr)
if (!ioctl (fd, SIOCGIFADDR, ifr2))
/* Print result for that interface */
}
Thanks, this works half! No need of ifr2, ifr is enough.
I saw the name change: 1.5 gives eth0, eth1, eth2, lo and 1.7 gives
{821C54BE-...}...
Careful - this isn't portable to newer BSDs, as there ifc_len may exceed
sizeof(struct ifreq).
getifaddrs() is probably the more portable solution here.
--
Matthias Andree
--
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/
Minor terminfo problem (was Re: Garbage man pages)
On Jun 18 10:36, Haojun Bao wrote: Dave Korn dave.korn.cyg...@googlemail.com writes: I said I'd check: there doesn't seem anything wrong with the packaging, which hasn't changed in a couple of years now; the most likely thing is that you and Bao experienced some kind of failure during running the postinstall scripts. Checking the log files /var/log/setup.* might show some indication of the problem. (But it also might not, error-handling paths are a known weakness in setup.exe.) Thanks:-) I can confirm your guess, the following lines are in my /var/log/setup.log: 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/man.sh 2009/06/04 18:06:50 abnormal exit: exit code=127 Here's a complete list of abnormal exits, note that I did 2 install, first time is default, second time is full-install. I used `grep abnormal -B 1 setup.log': 2009/06/04 18:06:44 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/000-cygwin-post-install.sh 2009/06/04 18:06:47 abnormal exit: exit code=127 Works fine for me. I just made a new 1.7 installation from scratch two days ago, and all the bash calls work as expected, except for a minor problem in the terminfo postinstall: 2009/06/16 11:13:37 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo0.sh chmod: cannot operate on dangling symlink `Eterm-color' 2009/06/16 11:13:45 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo.sh chmod: cannot operate on dangling symlink `Eterm-color' ETerm-color points to ../E/ETerm, but the directory is called 'e', not 'E'. That's a problem when using case-sensitivity like on a couple of my test machines. Chuck? Can you fix this in a manner which also works on case-sensitive filesyatems, please? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: [PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
2009/6/16 Corinna Vinschen corinna-cyg...@cygwin.com: On Jun 15 23:35, IWAMURO Motonori wrote: 2009/6/15 Corinna Vinschen: If everybody agrees to this suggestion, here's the patch. Is the name of modifier prefix cjk- good? It influences not CJK characters but a part of symbols and European characters. Please refer to Andy's opinion: http://cygwin.com/ml/cygwin/2009-06/msg00240.html It personally proposes ambinarrow because the switch of Vim is ambiwidth. I think cjk in the name is the right choice. ?There are no ambiguous characters in western languages (well, probably there are, but the ambiguity is not on the level of character widths). ?This is a problem which only has a meaning in these so called CJK languages. ?It makes sense to me to use this in the modifier name. I agree with keeping cjk in the modifier name (also because the xterm option is called -cjk_width) but for the historic understanding, it's actually quite the other way round: In traditional CJK character encodings, fonts, and terminal applications, basically ALL characters were wide, including a subset of Latin characters as it happened to be included in those character sets, and sometimes even including the ASCII range. These are the ones considered ambiguous since they used to be wide, while in all non-CJK environments they are not (excluding ASCII which is thus mirrored in the range Halfwidth and Fullwidth Forms, U+FF00 ... U+FF5E). This also explains the chaotic mix of wide and narrow characters in ranges like Latin-1 Supplement, Latin Extended, Greek and Cyrillic which is in no way useful for any user; it's just a legacy compatibility issue. I think the major usage for CJK users nowadays is about ranges like Arrows, Enclosed Alphanumerics (with circled digits), Box Drawing etc. And, I don't think that it is symmetrical. How about the following patch? (I have not changed the name of modifier prefix) I'm not convinced that we need symmetry. ?It looks like a nice idea for Cygwin or newlib, given that the setlocale language string is checked and picked to pieces hardcoded in the loadlocale function. Despite IWAMURO Motonori's withdrawal, I think symmetry would be the right approach to take. The major aspect is how to reflect the actual behaviour of existing terminal environments. And as a matter of fact, you can run both xterm and MinTTY with a non-CJK locale and ambiguous characters being wide. This is achieved by invoking xterm -cjk_width or by selecting an according font in MinTTY, e.g. Ming, SimSun, MS Mincho, or even just the popular Lucida Typewriter. (Although it occurs to me that in the case of Lucida Typewriter this might be a bug since the wideness of ambiguous characters is just simulated in this configuration rather than using wide font characters - Andy, can you please check this?) However, besides of being unnecessary, other systems like Linux or BSD use the language string as directory name relative to the /usr/share/locale directory. ?If this gets ever used on non-Cygwin systems, the symmetry (which has no precedent in the locale arena) would require these systems to create yet another subdirectory or symlink for the same purpose. ?Even worse, if you propose that @cjkwide is a valid modifier for *any* language, you would make the whole mechanism on non-newlib based systems more complicated for no apparent reason. The silly unmodular way that some systems implement the locale mechanism (the worst of them being SunOS) should not be an argument to not propagate a reasonable solution. [Who was in favour of these double negations?] The locale interface (syntax and semantics of LC_* strings) is defined in a modular way and so the implementations should be - let them fix it. Thomas -- 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: Minor terminfo problem (was Re: Garbage man pages)
On Thu, Jun 18, 2009 at 11:46:50AM +0200, Corinna Vinschen wrote: On Jun 18 10:36, Haojun Bao wrote: Dave Korn dave.korn.cyg...@googlemail.com writes: I said I'd check: there doesn't seem anything wrong with the packaging, which hasn't changed in a couple of years now; the most likely thing is that you and Bao experienced some kind of failure during running the postinstall scripts. Checking the log files /var/log/setup.* might show some indication of the problem. (But it also might not, error-handling paths are a known weakness in setup.exe.) Thanks:-) I can confirm your guess, the following lines are in my /var/log/setup.log: 2009/06/04 18:06:49 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/man.sh 2009/06/04 18:06:50 abnormal exit: exit code=127 Here's a complete list of abnormal exits, note that I did 2 install, first time is default, second time is full-install. I used `grep abnormal -B 1 setup.log': 2009/06/04 18:06:44 running: C:\cygwin\bin\bash.exe --norc --noprofile -c /etc/postinstall/000-cygwin-post-install.sh 2009/06/04 18:06:47 abnormal exit: exit code=127 Works fine for me. I just made a new 1.7 installation from scratch two days ago, and all the bash calls work as expected, except for a minor problem in the terminfo postinstall: 2009/06/16 11:13:37 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo0.sh chmod: cannot operate on dangling symlink `Eterm-color' 2009/06/16 11:13:45 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo.sh chmod: cannot operate on dangling symlink `Eterm-color' ETerm-color points to ../E/ETerm, but the directory is called 'e', not 'E'. That's a problem when using case-sensitivity like on a couple of my test machines. Chuck? Can you fix this in a manner which also works on case-sensitive filesyatems, please? Maybe we should fix this in setup.exe too by setting the terminal type to dumb. In fact, maybe we should cleanse the environment in setup.exe before running any program, if we aren't doing that already. cgf -- 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: [PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
On Jun 18 14:09, thomas.wo...@nsn.com wrote: 2009/6/16 Corinna Vinschen However, besides of being unnecessary, other systems like Linux or BSD use the language string as directory name relative to the /usr/share/locale directory. ?If this gets ever used on non-Cygwin systems, the symmetry (which has no precedent in the locale arena) would require these systems to create yet another subdirectory or symlink for the same purpose. ?Even worse, if you propose that @cjkwide is a valid modifier for *any* language, you would make the whole mechanism on non-newlib based systems more complicated for no apparent reason. The silly unmodular way that some systems implement the locale mechanism (the worst of them being SunOS) should not be an argument to not propagate a reasonable solution. [Who was in favour of these double negations?] The locale interface (syntax and semantics of LC_* strings) is defined in a modular way and so the implementations should be - let them fix it. What do you think, how big will be the acceptance of this approach outside of newlib/Cygwin? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: Minor terminfo problem (was Re: Garbage man pages)
On Jun 18 10:07, Christopher Faylor wrote: On Thu, Jun 18, 2009 at 11:46:50AM +0200, Corinna Vinschen wrote: 2009/06/16 11:13:45 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo.sh chmod: cannot operate on dangling symlink `Eterm-color' ETerm-color points to ../E/ETerm, but the directory is called 'e', not 'E'. That's a problem when using case-sensitivity like on a couple of my test machines. Chuck? Can you fix this in a manner which also works on case-sensitive filesyatems, please? Maybe we should fix this in setup.exe too by setting the terminal type to dumb. In fact, maybe we should cleanse the environment in setup.exe before running any program, if we aren't doing that already. This isn't really a problem of the $TERM environment setting. It's just a call to chmod which goes wrong because the directory E is actually called e, You'll only notice that on case-sensitive systems. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: UAC .manifest files
On 04/06/2009 11:11, Dave Korn wrote:
Sounds like a job for libtool, not automake. :)
Unfortunately, it looks like that's not a joke after all.
Look at func_mode_link (omitting some lines for clarity):
*cygwin* | *mingw* )
cwrappersource=$output_path/$objdir/lt-$output_name.c
cwrapper=$output_path/$output_name.exe
$RM $cwrappersource $cwrapper
func_emit_cwrapperexe_src $cwrappersource
$LTCC $LTCFLAGS -o $cwrapper $cwrappersource
$STRIP $cwrapper
$cwrapper --lt-dump-script $func_ltwrapper_scriptname_result
IOW, the cwrapper source is created and built, then the cwrapper is run
to create the ltwrapper ($objdir/${output_name}_ltshwrapper). But if
the target .exe has one of those names that trigger UAC, the last step
fails and the ltwrapper is empty. So not only can you not run the
program in-place, but worse, during install, the cwrapper is installed
instead of the real program, which obviously isn't very helpful.
So yes, in order for libtool to work with UAC, libtool needs to generate
a .manifest for both the $cwrapper in the $output_path (*before* the
lt-dump-script call) AND the real program in $objdir, so that running
in-place works. Whether it's libtool's responsibility to *install* the
latter is debatable.
Since I already have a libtool patch pending, I'll see if I can fix this
as well.
Chuck, any thoughts?
Yaakov
--
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/
[1.7] compile error after updating 1.7
hi! I just decided to update my 1.7 cygwin to the latest release it seems to run more smoothly now than in previous release :) however I'm getting strange errors when try to compile a project I'm working on I didn't get this on previous release I tryed to clean and rebuild everything and same result cc -shared -o GENERATED/libglui-0.0.1.dll -Wl,--out-implib=GENERATED/libglui-0.0.1.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--no-whole-archive -lGLU -lGL -L/usr/X11R6/lib -lglut -L/bin GENERATED/algebra3.o GENERATED/button.o GENERATED/callback.o GENERATED/collapsible.o GENERATED/container.o GENERATED/control.o GENERATED/debug.o GENERATED/DefaultTheme.o GENERATED/event_handler.o GENERATED/Exception.o GENERATED/imKStoUCS.o GENERATED/LightningTheme.o GENERATED/MasterObject.o GENERATED/node.o GENERATED/separator.o GENERATED/statictext.o GENERATED/text.o GENERATED/themes.o GENERATED/todo.o GENERATED/VertexObject.o GENERATED/window.o GENERATED/GLUT/window.o GENERATED/button.o:button.cpp:(.text+0x47): undefined reference to `___gxx_personality_sj0' GENERATED/button.o:button.cpp:(.text+0x161): undefined reference to `___gxx_personality_sj0' GENERATED/button.o:button.cpp:(.text+0x2ec): undefined reference to `___gxx_personality_sj0' GENERATED/button.o:button.cpp:(.text+0x3fc): undefined reference to `___gxx_personality_sj0' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI6ButtonE[typeinfo for GLUI::Button]+0x0): undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI16EventInterpreterE[typeinfo for GLUI::EventInterpreter]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI12EventHandlerE[typeinfo for GLUI::EventHandler]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI9ContainerE[typeinfo for GLUI::Container]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI7ControlE[typeinfo for GLUI::Control]+0x0): undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI4NodeE[typeinfo for GLUI::Node]+0x0): undefined reference to `vtable for __cxxabiv1::__class_type_info' GENERATED/button.o:button.cpp:(.rdata$_ZTIN4GLUI10TextButtonE[typeinfo for GLUI::TextButton]+0x0): undefined reference to `vtable for __cxxabiv1::__si_class_type_info' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI6ButtonD0Ev[GLUI::Button::~Button()]+0x31): undefined reference to `operator delete(void*)' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI10TextButtonD1Ev[GLUI::TextButton::~TextButton()]+0x1f): undefined reference to `___gxx_personality_sj0' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI10TextButtonD1Ev[GLUI::TextButton::~TextButton()]+0x93): undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI10TextButtonD1Ev[GLUI::TextButton::~TextButton()]+0x15b): undefined reference to `std::basic_stringchar, std::char_traitschar, std::allocatorchar ::_Rep::_M_destroy(std::allocatorchar const)' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI10TextButtonD0Ev[GLUI::TextButton::~TextButton()]+0x1f): undefined reference to `___gxx_personality_sj0' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI10TextButtonD0Ev[GLUI::TextButton::~TextButton()]+0x93): undefined reference to `__gnu_cxx::__exchange_and_add(int volatile*, int)' GENERATED/button.o:button.cpp:(.text$_ZN4GLUI10TextButtonD0Ev[GLUI::TextButton::~TextButton()]+0xe2): undefined reference to `operator delete(void*)' any idea? thanks JLM -- KISS! (Keep It Simple, Stupid!) (garde le simple, imbécile!) mais qu'est-ce que tu m'as pondu comme usine à gaz? fait des choses simples et qui marchent, espèce d'imbécile! - Si vous pensez que vous êtes trop petit pour changer quoique ce soit, essayez donc de dormir avec un moustique dans votre chambre. Betty Reese http://www.grainesdechangement.com/citations.htm -- 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: [1.7] compile error after updating 1.7
On Thu, Jun 18, 2009 at 06:39:56PM +0200, jean-luc malet wrote: I just decided to update my 1.7 cygwin to the latest release it seems to run more smoothly now than in previous release :) however I'm getting strange errors when try to compile a project I'm working on I didn't get this on previous release I tryed to clean and rebuild everything and same result cc -shared -o GENERATED/libglui-0.0.1.dll -Wl,--out-implib=GENERATED/libglui-0.0.1.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--no-whole-archive -lGLU -lGL -L/usr/X11R6/lib -lglut -L/bin GENERATED/algebra3.o GENERATED/button.o GENERATED/callback.o GENERATED/collapsible.o GENERATED/container.o GENERATED/control.o GENERATED/debug.o GENERATED/DefaultTheme.o GENERATED/event_handler.o GENERATED/Exception.o GENERATED/imKStoUCS.o GENERATED/LightningTheme.o GENERATED/MasterObject.o GENERATED/node.o GENERATED/separator.o GENERATED/statictext.o GENERATED/text.o GENERATED/themes.o GENERATED/todo.o GENERATED/VertexObject.o GENERATED/window.o GENERATED/GLUT/window.o We really do need the information mentioned here: http://cygwin.com/problems.html -- 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: [1.7] compile error after updating 1.7
jean-luc malet wrote: hi! I just decided to update my 1.7 cygwin to the latest release it seems to run more smoothly now than in previous release :) however I'm getting strange errors when try to compile a project I'm working on I didn't get this on previous release I tryed to clean and rebuild everything and same result cc -shared -o GENERATED/libglui-0.0.1.dll What is this? -Wl,--out-implib=GENERATED/libglui-0.0.1.dll.a -Wl,--export-all-symbols -Wl,--enable-auto-import -Wl,--no-whole-archive -lGLU -lGL -L/usr/X11R6/lib -lglut -L/bin GENERATED/algebra3.o GENERATED/button.o GENERATED/callback.o GENERATED/collapsible.o GENERATED/container.o GENERATED/control.o GENERATED/debug.o GENERATED/DefaultTheme.o GENERATED/event_handler.o GENERATED/Exception.o GENERATED/imKStoUCS.o GENERATED/LightningTheme.o GENERATED/MasterObject.o GENERATED/node.o GENERATED/separator.o GENERATED/statictext.o GENERATED/text.o GENERATED/themes.o GENERATED/todo.o GENERATED/VertexObject.o GENERATED/window.o GENERATED/GLUT/window.o It looks like you've maybe got a mix of gcc-3 objects (using sjlj exceptions) and are trying to link them against gcc-4's shared libgcc (uses Dwarf-2 exceptions). cheers, DaveK -- 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: browse-url in emacs (was Re: w32-shell-execute function definition is void)
On 6/17/2009 12:15 PM, Ken Brown wrote:
This turned out to be easier to sort out than I thought it would be.
I've sent a report to emacs-devel:
http://lists.gnu.org/archive/html/emacs-devel/2009-06/msg00320.html
I've now sent a patch upstream to fix the browse-url problem. (I
decided to do it without implementing w32-shell-execute.) It may be a
while before I know whether the patch, or some variant of it, is
accepted. This certainly won't happen until after the release of 23.1.
So I applied the patch locally and rebuilt the packages (cygwin 1.7
only). It works for me, but it would be good if someone else would test
it also.
Marc, if you want to test it, delete the stuff you added to your .emacs
and carry out the following steps:
D=http://www.math.cornell.edu/~kbrown/cygwin-1.7
wget -x -nH --cut-dirs=2 \
${D}/emacs/emacs-23.0.92-11.tar.bz2 \
${D}/emacs/emacs-X11/emacs-X11-23.0.92-11.tar.bz2 \
${D}/emacs/emacs-el/emacs-el-23.0.92-11.tar.bz2
/etc/preremove/emacs.sh
/etc/preremove/emacs-X11.sh
cd emacs
tar -C/ -xf emacs-23.0.92-11.tar.bz2
tar -C/ -xf emacs-X11/emacs-X11-23.0.92-11.tar.bz2
tar -C/ -xf emacs-el/emacs-el-23.0.92-11.tar.bz2
/etc/postinstall/emacs.sh
/etc/postinstall/emacs-X11.sh
If I haven't made a mistake, browse-url should now work. If anything
goes wrong, you can simply use setup-1.7.exe to reinstall emacs.
Ken
--
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: UAC .manifest files
On 18/06/2009 10:56, Yaakov (Cygwin/X) wrote:
Since I already have a libtool patch pending, I'll see if I can fix this
as well.
Here's a patch. Chuck?
Yaakov
--- origsrc/libtool-2.2.7a/libltdl/config/ltmain.m4sh 2009-06-15 00:06:10.0 -0500
+++ src/libtool-2.2.7a/libltdl/config/ltmain.m4sh 2009-06-18 11:49:49.913954500 -0500
@@ -3748,6 +3748,32 @@ EOF
}
# end: func_emit_cwrapperexe_src
+# func_emit_exe_manifest
+# emit a Win32 UAC manifest for executable on stdout
+# Must ONLY be called from within func_mode_link because
+# it depends on a number of variable set therein.
+func_emit_exe_manifest()
+{
+cat EOF
+?xml version=1.0 encoding=UTF-8 standalone=yes?
+assembly xmlns=urn:schemas-microsoft-com:asm.v1 manifestVersion=1.0
+ assemblyIdentity version=1.0.0.0
+ processorArchitecture=X86
+ name=$host_os.$PROGRAM.$outputname
+ type=win32/
+
+ !-- Identify the application security requirements. --
+ trustInfo xmlns=urn:schemas-microsoft-com:asm.v3
+security
+ requestedPrivileges
+requestedExecutionLevel level=asInvoker uiAccess=false/
+ /requestedPrivileges
+/security
+ /trustInfo
+/assembly
+EOF
+}
+
# func_win32_import_lib_p ARG
# True if ARG is an import lib, as indicated by $file_magic_cmd
func_win32_import_lib_p ()
@@ -7578,6 +7604,13 @@ EOF
$opt_dry_run || {
# note: this script will not be executed, so do not chmod.
if test x$build = x$host ; then
+ # Create the UAC manifests first if necessary
+ case $output_name in
+ *instal*|*patch*|*setup*|*update*)
+ func_emit_exe_manifest $cwrapper.manifest
+ func_emit_exe_manifest $output_path/$objdir/$output_name.exe.manifest
+ ;;
+ esac
$cwrapper --lt-dump-script $func_ltwrapper_scriptname_result
else
func_emit_wrapper no $func_ltwrapper_scriptname_result
--
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: UAC .manifest files
Den 2009-06-18 20:14 skrev Yaakov (Cygwin/X): On 18/06/2009 10:56, Yaakov (Cygwin/X) wrote: Since I already have a libtool patch pending, I'll see if I can fix this as well. Here's a patch. Chuck? There is a pending patch for libtool that adds MSVC support. That patch will not need this, so please special case this to only be active for gcc (and whatever else needs it). (but why do I bother responding to your mails when you don't respond to mine?) Cheers, Peter -- 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 to run GNU Emacs from Windows icon
On 6/4/2009 12:10 PM, David Karr wrote: emacs: Terminal type cygwin is not defined. My guess is that this is a terminfo issue. Try installing the terminfo0 package. Getting back to this, I already have terminfo0 installed. I think the cause of your problem with emacs-21 may have been found: http://cygwin.com/ml/cygwin/2009-06/msg00615.html Anyway, I hope you're happily using emacs-23 now so that this is no longer relevant. (emacs-23 depends on terminfo rather than terminfo0.) Ken -- 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: UAC .manifest files
On 18/06/2009 13:31, Peter Rosin wrote: There is a pending patch for libtool that adds MSVC support. That patch will not need this, so please special case this to only be active for gcc (and whatever else needs it). AFAICS from your patches, you're not using ltwrappers right now. If wrappers_required=no (which you may need to set), func_mode_link() exit()s before this point, so it should be moot. If that premise changes, it will need to be dealt with then; I can only work with what's in libtool right now. Yaakov -- 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/
help? compile error cygwin 1.7, multiple definition
Any suggestions or feedback on fixing this compile error would be appreciated. cygwin 1.7, gcc (GCC) 4.3.2 20080827 (beta) 2 mpd sources, any version $ ./autogen.sh --enable-oss --disable-ao --disable-un $ make make fails. Basically, the final compile and link command seems to fail because of multiple definition errors. Here it is: /usr/bin/g++ -g -O2 -o src/mpd.exe src_mpd-input_stream.o (... about a page of other .o files ) -Wl,--enable-auto-import -lm -lFLAC -lm -lgthread-2.0 -lglib-2.0 -lintl -liconv I added -Wl,--enable-auto-import which removes some other messages which don't seem to be the primary problem. Here is the output: src_mpd-file_input_plugin.o: In function `g_bit_nth_lsf': /usr/include/glib-2.0/glib/gutils.h:277: multiple definition of `_g_bit_nth_lsf' src_mpd-input_stream.o:/usr/include/glib-2.0/glib/gutils.h:277: first defined here src_mpd-file_input_plugin.o: In function `g_bit_nth_msf': /usr/include/glib-2.0/glib/gutils.h:290: multiple definition of `_g_bit_nth_msf' src_mpd-input_stream.o:/usr/include/glib-2.0/glib/gutils.h:290: first defined here ... these messages go on for pages, naming almost every .o file, then ends with: collect2: ld returned 1 exit status - Ian Kelling -- 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 to run GNU Emacs from Windows icon
-Original Message- From: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] On Behalf Of Ken Brown Sent: Thursday, June 18, 2009 11:35 AM To: cygwin@cygwin.com Subject: Re: How to run GNU Emacs from Windows icon On 6/4/2009 12:10 PM, David Karr wrote: emacs: Terminal type cygwin is not defined. My guess is that this is a terminfo issue. Try installing the terminfo0 package. Getting back to this, I already have terminfo0 installed. I think the cause of your problem with emacs-21 may have been found: http://cygwin.com/ml/cygwin/2009-06/msg00615.html Anyway, I hope you're happily using emacs-23 now so that this is no longer relevant. (emacs-23 depends on terminfo rather than terminfo0.) It is working fine, but I have a feeling the solution I ended up using probably would have worked in the regular version also. My shortcut command line is (paraphrased) rxvt bash emacs. I'm not going to worry too much about it at this point. Thanks. -- 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? compile error cygwin 1.7, multiple definition
Ian Kelling wrote: Any suggestions or feedback on fixing this compile error would be appreciated. cygwin 1.7, gcc (GCC) 4.3.2 20080827 (beta) 2 mpd sources, any version $ ./autogen.sh --enable-oss --disable-ao --disable-un $ make make fails. Basically, the final compile and link command seems to fail because of multiple definition errors. Here it is: /usr/bin/g++ -g -O2 -o src/mpd.exe src_mpd-input_stream.o (... about a page of other .o files ) -Wl,--enable-auto-import -lm -lFLAC -lm -lgthread-2.0 -lglib-2.0 -lintl -liconv I added -Wl,--enable-auto-import which removes some other messages which don't seem to be the primary problem. Here is the output: src_mpd-file_input_plugin.o: In function `g_bit_nth_lsf': /usr/include/glib-2.0/glib/gutils.h:277: multiple definition of `_g_bit_nth_lsf' src_mpd-input_stream.o:/usr/include/glib-2.0/glib/gutils.h:277: first defined here src_mpd-file_input_plugin.o: In function `g_bit_nth_msf': /usr/include/glib-2.0/glib/gutils.h:290: multiple definition of `_g_bit_nth_msf' src_mpd-input_stream.o:/usr/include/glib-2.0/glib/gutils.h:290: first defined here This sounds allot like this bug to me: https://bugzilla.redhat.com/show_bug.cgi?id=428865 Since Cygwin's glib2 is only at 2.10.3, you'll either need to wait for an update of this package or build a newer one yourself. Also, the repeating of -lm above could be troublesome. If you have problems related to this, try removing one. I'd recommend the first occurrence. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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? compile error cygwin 1.7, multiple definition
Larry Hall (Cygwin) wrote: Ian Kelling wrote: /usr/bin/g++ -g -O2 -o src/mpd.exe src_mpd-input_stream.o (... about a page of other .o files ) -Wl,--enable-auto-import -lm -lFLAC -lm -lgthread-2.0 -lglib-2.0 -lintl -liconv I added -Wl,--enable-auto-import which removes some other messages which don't seem to be the primary problem. Here is the output: src_mpd-file_input_plugin.o: In function `g_bit_nth_lsf': /usr/include/glib-2.0/glib/gutils.h:277: multiple definition of `_g_bit_nth_lsf' src_mpd-input_stream.o:/usr/include/glib-2.0/glib/gutils.h:277: first defined here src_mpd-file_input_plugin.o: In function `g_bit_nth_msf': /usr/include/glib-2.0/glib/gutils.h:290: multiple definition of `_g_bit_nth_msf' src_mpd-input_stream.o:/usr/include/glib-2.0/glib/gutils.h:290: first defined here This sounds allot like this bug to me: https://bugzilla.redhat.com/show_bug.cgi?id=428865 Since Cygwin's glib2 is only at 2.10.3, you'll either need to wait for an update of this package or build a newer one yourself. Hack: in /usr/include/glib-2.0/glib/gutils.h, at this point: 99 #elif defined (__GNUC__) 100 # define G_INLINE_FUNC extern inline 101 #elif defined (G_CAN_INLINE) delete 'extern' from line 100. (Then rebuild from clean.) cheers, DaveK -- 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: browse-url in emacs (was Re: w32-shell-execute function definition is void)
Ken Brown-6 wrote: On 6/17/2009 12:15 PM, Ken Brown wrote: Marc, if you want to test it, delete the stuff you added to your .emacs and carry out the following steps: ... OK, I ran this. I did it from within emacs, which was maybe not bright. Anyway, I got a couple of glitches in the postinstall: /etc/postinstall/emacs.sh: line 9: /usr/bin/update-desktop-database: No such file or directory /etc/postinstall/emacs.sh: line 10: /usr/bin/update-mime-database: No such file or directory Probably nothing. And now, (browse-url file:///C:/cygwin/home/marc/public_html nil) opened me an Explorer window, instead of the html page in Firefox... but: (browse-url file:///C:/cygwin/home/marc/public_html/user/index.html nil) did it! Yes, in fact, this looks just right. Thanks, and congratulations! Marc -- View this message in context: http://www.nabble.com/w32-shell-execute-function-definition-is-void-tp4718394p24099617.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: [PATCH] Add @cjknarrow modifier (was Re: [Fwd: [1.7] wcwidth failing configure tests])
2009/6/18 Thomas.Wolff: And as a matter of fact, you can run both xterm and MinTTY with a non-CJK locale and ambiguous characters being wide. This is achieved by invoking xterm -cjk_width or by selecting an according font in MinTTY, e.g. Ming, SimSun, MS Mincho, or even just the popular Lucida Typewriter. (Although it occurs to me that in the case of Lucida Typewriter this might be a bug since the wideness of ambiguous characters is just simulated in this configuration rather than using wide font characters - Andy, can you please check this?) Yep, there's a problem here, thanks. I haven't got Lucida Typewriter, but found my Vista install has Lucida Sans Typewriter. That font doesn't actually have Greek or box drawing characters, so all I'm getting is the square replacement character, but it does indeed take up two cells for those. Turns out that's because Latin characters are reported as having a width of 0.5 (of whatever unit) whereas the replacement character is reported as being 0.625 wide. I'll adjust the ambiguous-width detection. Andy -- 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? compile error cygwin 1.7, multiple definition
Dave Korn wrote: Larry Hall (Cygwin) wrote: This sounds allot like this bug to me: https://bugzilla.redhat.com/show_bug.cgi?id=428865 Since Cygwin's glib2 is only at 2.10.3, you'll either need to wait for an update of this package or build a newer one yourself. Hack: in /usr/include/glib-2.0/glib/gutils.h, at this point: 99 #elif defined (__GNUC__) 100 # define G_INLINE_FUNC extern inline 101 #elif defined (G_CAN_INLINE) delete 'extern' from line 100. (Then rebuild from clean.) Looks like you guys got it exactly and the hack worked. Thanks a ton. - Ian Kelling -- 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: browse-url in emacs
On 6/18/2009 4:58 PM, Marc Girod wrote: I did it from within emacs, which was maybe not bright. It just means that you were trying to replace some in-use files. This should work in cygwin 1.7, though you might have to exit and restart emacs to see the effect in some situations. Anyway, I got a couple of glitches in the postinstall: /etc/postinstall/emacs.sh: line 9: /usr/bin/update-desktop-database: No such file or directory /etc/postinstall/emacs.sh: line 10: /usr/bin/update-mime-database: No such file or directory Harmless. (browse-url file:///C:/cygwin/home/marc/public_html nil) opened me an Explorer window, instead of the html page in Firefox... I implemented browse-url using cygstart. I think this means that it should open whatever browser you would get by doing Start - Run and typing the URL. Thanks, and congratulations! Thanks for testing. Ken -- 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? compile error cygwin 1.7, multiple definition
On 18/06/2009 16:03, Dave Korn wrote: Hack: in /usr/include/glib-2.0/glib/gutils.h, at this point: 99 #elif defined (__GNUC__) 100 # define G_INLINE_FUNC extern inline 101 #elif defined (G_CAN_INLINE) delete 'extern' from line 100. (Then rebuild from clean.) For the record, this has already been fixed upstream in the current release. I've just got to get around to merging the Ports packages back into the distro. Yaakov -- 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: Minor terminfo problem (was Re: Garbage man pages)
Corinna Vinschen wrote: Works fine for me. I just made a new 1.7 installation from scratch two days ago, and all the bash calls work as expected, except for a minor problem in the terminfo postinstall: 2009/06/16 11:13:37 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo0.sh chmod: cannot operate on dangling symlink `Eterm-color' The whole reason for the two different terminfo databases was to (eventually) make the old one obsolete, precisely because it has problems with case sensitivity. The fix here is to (eventually) recompile client applications to use ncurses-5.7 (e.g. cygncurses-9.dll). Older ncurses/terminfo is just broken. Always has been (on cygwin). 2009/06/16 11:13:45 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo.sh chmod: cannot operate on dangling symlink `Eterm-color' ETerm-color points to ../E/ETerm, but the directory is called 'e', Eterm-color ../E/Eterm (lowercase 't') not 'E'. That's a problem when using case-sensitivity like on a couple of my test machines. Errr...that should only be true for terminfo0, in that: $ ls -l e/Eterm* -rw-r--r-- e/Eterm lrwxrwxrwx e/Eterm-color - ../E/Eterm However, for modern terminfo, $ ls -l 45/Eterm* -rw-r--r-- 45/Eterm -rw-r--r-- 45/Eterm-256color -rw-r--r-- 45/Eterm-88color lrwxrwxrwx 45/Eterm-color - ../45/Eterm So, this puzzles me: 2009/06/16 11:13:45 running: C:\cygwin-1.7\bin\bash.exe --norc --noprofile -c /etc/postinstall/terminfo.sh chmod: cannot operate on dangling symlink `Eterm-color' as I don't quite understand why that is failing, even on a case-sensitive system. Chuck? Can you fix this in a manner which also works on case-sensitive filesyatems, please? No, and maybe. terminfo0 and terminfo0-extra are WONTFIX, because the actual *fix* is to use newer ncurses, and terminfo/terminfo-extra. That was the whole point. As far as fixing terminfo/terminfo-extra, I need a bit more information about WHY it's failing. AFAICT there should be no case-related issues in those packages. -- Chuck -- 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/
