Re: [ANNOUNCEMENT] New package: guile-1.5.6-3

Re: [ANNOUNCEMENT] New package: guile-1.5.6-3

[Steven O'Brien]

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/

Re: [ANNOUNCEMENT] New package: guile-1.5.6-3

[Charles Wilson]

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/

Re: [ANNOUNCEMENT] New package: guile-1.5.6-3

[Christopher Faylor]

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/

Re: [ANNOUNCEMENT] New package: guile-1.5.6-3

[Charles Wilson]

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/

binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3]

[Charles Wilson]

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/

Re: binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3]

[Christopher Faylor]

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/

Re: binutils with Egor's patch [was: Re: [ANNOUNCEMENT] New package: guile-1.5.6-3]

[egor duda]

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/