* Re: [ANNOUNCEMENT] New package: guile-1.5.6-3 [not found] <87fzystrvz.fsf@peder.flower> @ 2002-07-10 14:25 ` Steven O'Brien 2002-07-10 14:42 ` Charles Wilson 0 siblings, 1 reply; 7+ messages in thread From: Steven O'Brien @ 2002-07-10 14:25 UTC (permalink / raw) To: cygwin Hi I have a problem with guile-devel. libguile/root.h exports: extern SCM scm_sys_protects[]; and #define's each array element as a macro When trying to compile gnumeric-1.0.8, the build fails with the message: "variable 'scm_sys_protects' can't be auto-imported." This is expected, as you cannot auto-import arrays. However, I cannot find any way of explicitly importing it without breaking the #define'd elements. Does anyone know how to do this? Or is this a case where the old-fashioned __declspec(dllimport) decoration is required? Thanks for any reply, Steven On Wed, 10 Jul 2002 01:15:28 +0200 Jan Nieuwenhuizen <janneke@gnu.org> wrote: > > Guile, the GNU extension language and Scheme interpreter and > libraries, have been included in the Cygwin distribution. > > Guile, the GNU Ubiquitous Intelligent Language for Extension, is a > scheme implementation designed for real world programming, supporting > a rich Unix interface, a module system, and undergoing rapid > development. `guile' is a scheme interpreter that can execute scheme > scripts (with a #! line at the top of the file), or run as an inferior > scheme process inside Emacs. > > Guile has been packaged in four parts: guile, guile-doc, guile-devel > and libguile14. > > For a brief description of what these packages are and what they > contain, see http://cygwin.com/packages/ . > > NOTE: This is the first Guile release as a Cygwin package; the first > version of Guile for Cygwin that uses and provides shared object > libraries (DLLs), and the first Cygwin package that links to libtool > (libltdl). As such, you may experience bugs never seen before. > > Please send questions or comments on Guile to the Cygwin mailing list > at: cygwin@cygwin.com. [However, if you're having problems related to > LilyPond, please write to lilypond-user@gnu.org.] > > Greetings, > Jan. > > > INSTALLATION: > > To update your installation, click on the "Install Cygwin now" link > on the http://cygwin.com/ web page. This downloads setup.exe to > your system. Save it and run setup, answer the questions and pick > up 'guile' from the 'Interpreters' category. > > Note that downloads from sources.redhat.com (aka cygwin.com) aren't > allowed due to bandwidth limitations. This means that you will need > to find a mirror which has this update. > > In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ > is a reliable high bandwidth connection, and already up to date. > > In Japan, use ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ . > > In Denmark, http://mirrors.sunsite.dk/cygwin/ is already up-to-date. > > If one of the above doesn't have the latest version of this package > you can either wait for the site to be updated or find another > mirror. > > Please send questions or comments to the Cygwin mailing list at: > cygwin@cygwin.com. If you want to subscribe go to: > http://cygwin.com/lists.html. I would appreciate if you would use > this mailing list rather than emailing me directly. This includes > ideas and comments about the setup utility or Cygwin in general. > > If you want to make a point or ask a question the Cygwin mailing > list is the appropriate place. > > *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** > > To unsubscribe to the cygwin-announce mailing list, look at the > "List-Unsubscribe: " tag in the email header of this message. Send > email to the address specified there. It will be in the format: > > cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@cygwin.com > > -- > Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music > typesetter http://www.xs4all.nl/~jantien | > http://www.lilypond.org > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCEMENT] New package: guile-1.5.6-3 2002-07-10 14:25 ` [ANNOUNCEMENT] New package: guile-1.5.6-3 Steven O'Brien @ 2002-07-10 14:42 ` Charles Wilson 2002-07-10 21:19 ` Christopher Faylor 0 siblings, 1 reply; 7+ messages in thread From: Charles Wilson @ 2002-07-10 14:42 UTC (permalink / raw) To: cygwin There is a patch pending to binutils that would allow this to work as-is. It seems to work okay, however, we're still waiting on Egor's legal paperwork -- an unfortunately, the only discussion has been between Egor and I; no other binutils-list readers have commented. I'd really rather not see a return of declspec()... Perhaps temporarily, we could use a workaround in both guile and guile-client code: in guile, new functions (with the obvious implementations): #ifdef __CYGWIN__ SCM get_scm_sys_protects(int index); void set_scm_sys_protects(SCM s, int index); #endif and in client code, replace assignments and reads with the appropriate function call, guarded by #ifdef __CYGWIN__ ? It's even possible that the guile folks would accept this sort of change, as an extension to their API (rather than actually *replacing* direct access to the array, which works just fine on all other platforms). Then, it would be up to client programs to choose direct access or get/set... --Chuck Steven O'Brien wrote: > Hi > > I have a problem with guile-devel. > libguile/root.h exports: > extern SCM scm_sys_protects[]; > > and #define's each array element as a macro > > When trying to compile gnumeric-1.0.8, the build fails with the message: > "variable 'scm_sys_protects' can't be auto-imported." > > This is expected, as you cannot auto-import arrays. However, I cannot > find any way of explicitly importing it without breaking the #define'd > elements. Does anyone know how to do this? Or is this a case where the > old-fashioned __declspec(dllimport) decoration is required? > > Thanks for any reply, > Steven > > > On Wed, 10 Jul 2002 01:15:28 +0200 > Jan Nieuwenhuizen <janneke@gnu.org> wrote: > > >>Guile, the GNU extension language and Scheme interpreter and >>libraries, have been included in the Cygwin distribution. >> >>Guile, the GNU Ubiquitous Intelligent Language for Extension, is a >>scheme implementation designed for real world programming, supporting >>a rich Unix interface, a module system, and undergoing rapid >>development. `guile' is a scheme interpreter that can execute scheme >>scripts (with a #! line at the top of the file), or run as an inferior >>scheme process inside Emacs. >> >>Guile has been packaged in four parts: guile, guile-doc, guile-devel >>and libguile14. >> >>For a brief description of what these packages are and what they >>contain, see http://cygwin.com/packages/ . >> >>NOTE: This is the first Guile release as a Cygwin package; the first >>version of Guile for Cygwin that uses and provides shared object >>libraries (DLLs), and the first Cygwin package that links to libtool >>(libltdl). As such, you may experience bugs never seen before. >> >>Please send questions or comments on Guile to the Cygwin mailing list >>at: cygwin@cygwin.com. [However, if you're having problems related to >>LilyPond, please write to lilypond-user@gnu.org.] >> >>Greetings, >>Jan. >> >> >>INSTALLATION: >> >>To update your installation, click on the "Install Cygwin now" link >>on the http://cygwin.com/ web page. This downloads setup.exe to >>your system. Save it and run setup, answer the questions and pick >>up 'guile' from the 'Interpreters' category. >> >>Note that downloads from sources.redhat.com (aka cygwin.com) aren't >>allowed due to bandwidth limitations. This means that you will need >>to find a mirror which has this update. >> >>In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ >>is a reliable high bandwidth connection, and already up to date. >> >>In Japan, use ftp://ftp.u-aizu.ac.jp/pub/gnu/gnu-win32/ . >> >>In Denmark, http://mirrors.sunsite.dk/cygwin/ is already up-to-date. >> >>If one of the above doesn't have the latest version of this package >>you can either wait for the site to be updated or find another >>mirror. >> >>Please send questions or comments to the Cygwin mailing list at: >>cygwin@cygwin.com. If you want to subscribe go to: >>http://cygwin.com/lists.html. I would appreciate if you would use >>this mailing list rather than emailing me directly. This includes >>ideas and comments about the setup utility or Cygwin in general. >> >>If you want to make a point or ask a question the Cygwin mailing >>list is the appropriate place. >> >>*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** >> >>To unsubscribe to the cygwin-announce mailing list, look at the >>"List-Unsubscribe: " tag in the email header of this message. Send >>email to the address specified there. It will be in the format: >> >>cygwin-announce-unsubscribe-YOU=YOURDOMAIN.COM@cygwin.com >> >>-- >>Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music >>typesetter http://www.xs4all.nl/~jantien | >>http://www.lilypond.org >> >> > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCEMENT] New package: guile-1.5.6-3 2002-07-10 14:42 ` Charles Wilson @ 2002-07-10 21:19 ` Christopher Faylor 2002-07-10 22:27 ` Charles Wilson 0 siblings, 1 reply; 7+ messages in thread From: Christopher Faylor @ 2002-07-10 21:19 UTC (permalink / raw) To: cygwin On Wed, Jul 10, 2002 at 03:48:38PM -0400, Charles Wilson wrote: >There is a patch pending to binutils that would allow this to work >as-is. It seems to work okay, however, we're still waiting on Egor's >legal paperwork -- an unfortunately, the only discussion has been >between Egor and I; no other binutils-list readers have commented. Should I make a "test" version of binutils available with Egor's patch? Oh wait. It needs a new version of cygwin1.dll first. I guess we have to release it as 1) cygwin and 2) binutils. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ANNOUNCEMENT] New package: guile-1.5.6-3 2002-07-10 21:19 ` Christopher Faylor @ 2002-07-10 22:27 ` Charles Wilson 2002-07-11 0:28 ` binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] Charles Wilson 0 siblings, 1 reply; 7+ messages in thread From: Charles Wilson @ 2002-07-10 22:27 UTC (permalink / raw) To: cygwin Christopher Faylor wrote: > On Wed, Jul 10, 2002 at 03:48:38PM -0400, Charles Wilson wrote: > >>There is a patch pending to binutils that would allow this to work >>as-is. It seems to work okay, however, we're still waiting on Egor's >>legal paperwork -- an unfortunately, the only discussion has been >>between Egor and I; no other binutils-list readers have commented. >> > > Should I make a "test" version of binutils available with Egor's patch? > > Oh wait. It needs a new version of cygwin1.dll first. I guess we have > to release it as 1) cygwin and 2) binutils. Err, not really. I can test his patched binutils under stock 1.3.12-2. That is, I can build a library with struct FOO_struct my_array[]. I can successfully build a client that accesses my_array[3].bob, and the runtime pseudo-relocation works just fine. As long as my client doesn't fork(). The reason for the cygwin patches, is so that the above works after a fork(), because the runtime pseudo-relocs have to be redone in the child. I think. So, the worst that could happen if you release a patched binutils but not cygwin, is that 1) IF some one exercised this feature 2) and they fork() 3) then it will break. But all existing working code will continue to work -- since with existing binutils we can't even LINK code that might exercise the feature. So, worst case: some new code (that currently doesn't work) might continue to not work -- except right now it's a build error; it'll become a runtime error (but only in fork()ed children). Right, Egor? Anyway, I think you should go ahead with a test release of binutils *before* a new cygwin release. --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] 2002-07-10 22:27 ` Charles Wilson @ 2002-07-11 0:28 ` Charles Wilson 2002-07-11 2:41 ` Christopher Faylor 2002-07-11 4:03 ` egor duda 0 siblings, 2 replies; 7+ messages in thread From: Charles Wilson @ 2002-07-11 0:28 UTC (permalink / raw) To: cygwin Also, while you're at it, how about this patch from Ralf: RE: cygwin ld import library issue fix (removing unused "_nm_" symbols) http://sources.redhat.com/ml/binutils/2002-04/msg00416.html After re-reading the whole thread, it seems that everybody (eventually) thought it'd be a good idea, but a check of CVSweb shows that it never actually got applied. --Chuck Charles Wilson wrote: > Christopher Faylor wrote: > >> On Wed, Jul 10, 2002 at 03:48:38PM -0400, Charles Wilson wrote: >> >>> There is a patch pending to binutils that would allow this to work >>> as-is. It seems to work okay, however, we're still waiting on Egor's >>> legal paperwork -- an unfortunately, the only discussion has been >>> between Egor and I; no other binutils-list readers have commented. >>> >> >> Should I make a "test" version of binutils available with Egor's patch? >> >> Oh wait. It needs a new version of cygwin1.dll first. I guess we have >> to release it as 1) cygwin and 2) binutils. > > > > Err, not really. > > I can test his patched binutils under stock 1.3.12-2. That is, I can > build a library with struct FOO_struct my_array[]. I can successfully > build a client that accesses my_array[3].bob, and the runtime > pseudo-relocation works just fine. > > As long as my client doesn't fork(). > > The reason for the cygwin patches, is so that the above works after a > fork(), because the runtime pseudo-relocs have to be redone in the > child. I think. > > So, the worst that could happen if you release a patched binutils but > not cygwin, is that > 1) IF some one exercised this feature > 2) and they fork() > 3) then it will break. > But all existing working code will continue to work -- since with > existing binutils we can't even LINK code that might exercise the feature. > > So, worst case: some new code (that currently doesn't work) might > continue to not work -- except right now it's a build error; it'll > become a runtime error (but only in fork()ed children). > > Right, Egor? > > Anyway, I think you should go ahead with a test release of binutils > *before* a new cygwin release. > > --Chuck > > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] 2002-07-11 0:28 ` binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] Charles Wilson @ 2002-07-11 2:41 ` Christopher Faylor 2002-07-11 4:03 ` egor duda 1 sibling, 0 replies; 7+ messages in thread From: Christopher Faylor @ 2002-07-11 2:41 UTC (permalink / raw) To: cygwin On Thu, Jul 11, 2002 at 12:20:44AM -0400, Charles Wilson wrote: >Also, while you're at it, how about this patch from Ralf: > RE: cygwin ld import library issue fix (removing unused "_nm_" symbols) > http://sources.redhat.com/ml/binutils/2002-04/msg00416.html > >After re-reading the whole thread, it seems that everybody (eventually) >thought it'd be a good idea, but a check of CVSweb shows that it never >actually got applied. Hmm. I remember that one. I'll add it to the next binutils release. If no one complains, I'll check it into the main trunk. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] 2002-07-11 0:28 ` binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] Charles Wilson 2002-07-11 2:41 ` Christopher Faylor @ 2002-07-11 4:03 ` egor duda 1 sibling, 0 replies; 7+ messages in thread From: egor duda @ 2002-07-11 4:03 UTC (permalink / raw) To: Charles Wilson; +Cc: cygwin Hi! CW> Charles Wilson wrote: >> Christopher Faylor wrote: >>> Should I make a "test" version of binutils available with Egor's patch? >>> >>> Oh wait. It needs a new version of cygwin1.dll first. I guess we have >>> to release it as 1) cygwin and 2) binutils. >> >> Err, not really. >> >> I can test his patched binutils under stock 1.3.12-2. That is, I can >> build a library with struct FOO_struct my_array[]. I can successfully >> build a client that accesses my_array[3].bob, and the runtime >> pseudo-relocation works just fine. >> >> As long as my client doesn't fork(). >> >> The reason for the cygwin patches, is so that the above works after a >> fork(), because the runtime pseudo-relocs have to be redone in the >> child. I think. >> >> So, the worst that could happen if you release a patched binutils but >> not cygwin, is that >> 1) IF some one exercised this feature >> 2) and they fork() >> 3) then it will break. >> But all existing working code will continue to work -- since with >> existing binutils we can't even LINK code that might exercise the feature. Absolutely right. >> So, worst case: some new code (that currently doesn't work) might >> continue to not work -- except right now it's a build error; it'll >> become a runtime error (but only in fork()ed children). >> >> Right, Egor? >> >> Anyway, I think you should go ahead with a test release of binutils >> *before* a new cygwin release. Ok, i'll try to clarify. The plan i suppose we should follow is. 0) Wait for all legal paperwork to be done. 1) Release patched binutils. By default they are not using pseudo-relocations, so everything should work as before. 2) Wait for some time until dust settles. 3) Patch cygwin and mingw runtimes to add 'relocator' function. I'll look if it's possible to move all initialization stuff to cygwin1.dll, as Chris suggested, so crt0.o is not changed. 4) Repeat step 2. :) 5) Start to update packages which want to use this feature. 6) Repeat step 2. :) 7) Patch binutils to make --enable-runtime-pseudo-reloc default. We can also swap steps 1 and 3, i.e. release patched cygwin and/or mingw first. This will require a tiny patch to binutils so that ld's linker script define __RUNTIME_PSEUDO_RELOC_LIST__ and __RUNTIME_PSEUDO_RELOC_LIST_END__ as, say, zeroes, or any other equal addresses. In this case call to relocator will do nothing until we release fully-patched binutils and someone uses pseudo relocations. Now about that fork() stuff: My test example has 2 'branches'. First one is for testing with updated runtimes which support pseudo relocations, and second one, which uses "manual" relocation code by implementing relocator inside of application code calling it in the first line of 'main()'. Chuck is right that every instance of program which uses pseudo relocations (including forked child) should be fixed up at startup. Actually, one can add call to _pei386_runtime_relocator in every place in program where fork () returns 0, and manual relocation will work fine there. You can try this: --- crtest.c Thu Jul 11 11:12:36 2002 +++ crtest.c.new Thu Jul 11 11:11:51 2002 @@ -50,5 +50,5 @@ main () &__RUNTIME_PSEUDO_RELOC_LIST_END__); #endif -#if defined(RUNTIME_PSEUDO_RELOC_SUPPORT) && defined(HAVE_FORK) +#if defined(HAVE_FORK) switch (pid = fork ()) { @@ -57,4 +57,8 @@ main () break; case 0: +#if !defined(RUNTIME_PSEUDO_RELOC_SUPPORT) + _pei386_runtime_relocator (&__RUNTIME_PSEUDO_RELOC_LIST__, + &__RUNTIME_PSEUDO_RELOC_LIST_END__); +#endif printf ("child: "); print_data (); But adding "manual" relocator is supposed to to be done for testing purposes only. Polluting package sources with such stuff is probably not what we want. Egor. mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/ ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2002-07-11 7:28 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <87fzystrvz.fsf@peder.flower> 2002-07-10 14:25 ` [ANNOUNCEMENT] New package: guile-1.5.6-3 Steven O'Brien 2002-07-10 14:42 ` Charles Wilson 2002-07-10 21:19 ` Christopher Faylor 2002-07-10 22:27 ` Charles Wilson 2002-07-11 0:28 ` binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3] Charles Wilson 2002-07-11 2:41 ` Christopher Faylor 2002-07-11 4:03 ` egor duda
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).