public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/44927]  New: static linkage with -lgomp fails on simple program
@ 2010-07-13  8:41 victor dot pasko at gmail dot com
  2010-07-13  9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
                   ` (13 more replies)
  0 siblings, 14 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13  8:41 UTC (permalink / raw)
  To: gcc-bugs

gfortran -static bug.f90 -lgomp -lpthread -lrt

./a.out << EOF
   -static@omp_get_max_threads
EOF

#0  0x0000000000000000 in ?? ()
#1  0x000000000040e345 in get_external_unit (n=5, do_create=1) at
/export/users/aagafono/gnu_4.5.0/gcc-4.5.0/libgfortran/../gcc/gthr-posix.h:767
#2  0x000000000040cecf in data_transfer_init (dtp=0x7fffdd077520, read_flag=1)
at /export/users/aagafono/gnu_4.5.0/gcc-4.5.0/libgfortran/io/transfer.c:2133
#3  0x00000000004002e7 in MAIN__ ()
#4  0x000000000040047d in main ()

% cat bug.f90
      program gompBUGonSTATIClinkagewithGNUfortran

      integer omp_get_max_threads
      integer n

      character*32 buf

      read *, buf

      n = omp_get_max_threads()

      print *, buf
      print *, n

      print *, 'TEST PASS'

      end


-- 
           Summary: static linkage with -lgomp fails on simple program
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: victor dot pasko at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
@ 2010-07-13  9:22 ` jakub at gcc dot gnu dot org
  2010-07-13  9:27 ` victor dot pasko at gmail dot com
                   ` (12 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-13  9:22 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from jakub at gcc dot gnu dot org  2010-07-13 09:22 -------
User bug.  If you link -lpthread statically (which you really shouldn't, static
linking is highly not recommended), you need to ensure it is linked in as whole
(i.e. -Wl,--whole-archive -lpthread -Wl,--no-whole-archive).


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
  2010-07-13  9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
@ 2010-07-13  9:27 ` victor dot pasko at gmail dot com
  2010-07-13 12:01 ` victor dot pasko at gmail dot com
                   ` (11 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13  9:27 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from victor dot pasko at gmail dot com  2010-07-13 09:27 -------
OK test PASSED after adding -Wl,--whole-archive -lpthread
-Wl,--no-whole-archive

But there is some strange warning:

% gfortran -static bug.f90 -lgomp -Wl,--whole-archive -lpthread
-Wl,--no-whole-archive -lrt
/usr/lib/../lib64/libpthread.a(sem_open.o): In function `sem_open':
(.text+0x448): warning: the use of `mktemp' is dangerous, better use `mkstemp'

vpasko@nstmklel143
/nfs/ins/proj/mkl/builds2/vpasko/10.3b1_lnx/mkl/examples/dftf
% ./a.out
sssss
 sssss
           8
 TEST PASS


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
  2010-07-13  9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
  2010-07-13  9:27 ` victor dot pasko at gmail dot com
@ 2010-07-13 12:01 ` victor dot pasko at gmail dot com
  2010-07-13 12:23 ` jakub at gcc dot gnu dot org
                   ` (10 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13 12:01 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from victor dot pasko at gmail dot com  2010-07-13 12:01 -------
I would like that it was possible to get correct static program by using just:

gfortran -static bug.f90 -fopenmp


-- 

victor dot pasko at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (2 preceding siblings ...)
  2010-07-13 12:01 ` victor dot pasko at gmail dot com
@ 2010-07-13 12:23 ` jakub at gcc dot gnu dot org
  2010-07-13 12:37 ` victor dot pasko at gmail dot com
                   ` (9 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-13 12:23 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #4 from jakub at gcc dot gnu dot org  2010-07-13 12:22 -------
It is not a gcc thing though, but glibc.  Some Linux distributions (e.g. recent
Fedora or RHEL) ld -r all libpthread.a objects together, so this works, others
do not.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (3 preceding siblings ...)
  2010-07-13 12:23 ` jakub at gcc dot gnu dot org
@ 2010-07-13 12:37 ` victor dot pasko at gmail dot com
  2010-07-13 17:08 ` jakub at gcc dot gnu dot org
                   ` (8 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-13 12:37 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from victor dot pasko at gmail dot com  2010-07-13 12:36 -------
The root cause of the problem is in using weak symbol pthread_cancel in unit.o
object from libgfortran.a library. Why it's so?

Look:

% nm unit.o
00000000000004f0 T _gfortrani_close_unit
00000000000004a0 T _gfortrani_close_units
                 U _gfortrani_error_stream
0000000000000a60 T _gfortrani_find_unit
                 U _gfortrani_free_mem
                 U _gfortrani_get_mem
0000000000000900 T _gfortrani_get_unit
                 U _gfortrani_init_loop_spec
0000000000000500 T _gfortrani_init_units
                 U _gfortrani_input_stream
                 U _gfortrani_internal_error
0000000000000170 T _gfortrani_is_array_io
0000000000000150 T _gfortrani_is_internal_unit
0000000000000008 C _gfortrani_max_offset
                 U _gfortrani_open_internal
                 U _gfortrani_options
                 U _gfortrani_output_stream
0000000000000000 B _gfortrani_unit_lock
0000000000000008 C _gfortrani_unit_root
0000000000000340 T _gfortrani_unlock_unit
0000000000000360 t close_unit_1
0000000000000040 t compare
0000000000000060 t delete_root
00000000000000d0 t delete_treap
0000000000000a50 T find_or_create_unit
0000000000000720 t find_unit_1
0000000000000180 t insert
0000000000000230 t insert_unit
0000000000000040 b internal_unit
                 U memset
                 w pthread_cancel
                 w pthread_mutex_lock
                 w pthread_mutex_trylock
                 w pthread_mutex_unlock
0000000000000000 t rotate_left
0000000000000020 t rotate_right
0000000000000110 b unit_cache
0000000000000000 d x0.6677


-- 

victor dot pasko at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (4 preceding siblings ...)
  2010-07-13 12:37 ` victor dot pasko at gmail dot com
@ 2010-07-13 17:08 ` jakub at gcc dot gnu dot org
  2010-07-14 10:11 ` victor dot pasko at gmail dot com
                   ` (7 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-13 17:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from jakub at gcc dot gnu dot org  2010-07-13 17:08 -------
Please don't keep reopening this bug.
The symbols are weak undefs because libgfortran doesn't require (and shouldn't
require) libpthread, it is thread-safe only when libpthread is linked in.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (5 preceding siblings ...)
  2010-07-13 17:08 ` jakub at gcc dot gnu dot org
@ 2010-07-14 10:11 ` victor dot pasko at gmail dot com
  2010-07-16  3:55 ` victor dot pasko at gmail dot com
                   ` (6 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-14 10:11 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from victor dot pasko at gmail dot com  2010-07-14 10:11 -------
(In reply to comment #6)
> Please don't keep reopening this bug.

Why? I disagree with your resolution.

> The symbols are weak undefs because libgfortran doesn't require (and shouldn't
> require) libpthread, it is thread-safe only when libpthread is linked in.

Therefore, I don't like that libgfortran works incorrectly in this case :(


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (6 preceding siblings ...)
  2010-07-14 10:11 ` victor dot pasko at gmail dot com
@ 2010-07-16  3:55 ` victor dot pasko at gmail dot com
  2010-07-16  4:29 ` kargl at gcc dot gnu dot org
                   ` (5 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-16  3:55 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from victor dot pasko at gmail dot com  2010-07-16 03:55 -------
You know, libgfortran works incorrectly with weak symbols from pthread :(
In case of static library it needs to call these functions only if its value is
not NULL.

So, the follwing is to be:

  if(pthread_cancel)
    {
       pthread_cancel(...);
    }
instead of just
    pthread_cancel(...);
as it is now.


-- 

victor dot pasko at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (7 preceding siblings ...)
  2010-07-16  3:55 ` victor dot pasko at gmail dot com
@ 2010-07-16  4:29 ` kargl at gcc dot gnu dot org
  2010-07-16  7:10 ` burnus at gcc dot gnu dot org
                   ` (4 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-07-16  4:29 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from kargl at gcc dot gnu dot org  2010-07-16 04:28 -------
(In reply to comment #6)
> Please don't keep reopening this bug.
> The symbols are weak undefs because libgfortran doesn't require (and shouldn't
> require) libpthread, it is thread-safe only when libpthread is linked in.
> 

After reviewing the thread (and recalling others along this line),
Jakub, if you want to make the combination of -static -fopenmp
a fatal error for gfortran, a patch is pre-approved.  Something
like
Index: options.c
===================================================================
--- options.c   (revision 161930)
+++ options.c   (working copy)
@@ -390,6 +390,9 @@ gfc_post_options (const char **pfilename
   if (pedantic && gfc_option.flag_whole_file)
     gfc_option.flag_whole_file = 2;

+  if (gfc_option.flag_openmp && THE_STATIC_FLAG)
+    gfc_fatal_error ("Conflicting options -fopenmp and -static");
+
   gfc_cpp_post_options ();

 /* FIXME: return gfc_cpp_preprocess_only ();

where I could not find the right flag for THE_STATIC_FLAG.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (8 preceding siblings ...)
  2010-07-16  4:29 ` kargl at gcc dot gnu dot org
@ 2010-07-16  7:10 ` burnus at gcc dot gnu dot org
  2010-07-16 14:48 ` kargl at gcc dot gnu dot org
                   ` (3 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: burnus at gcc dot gnu dot org @ 2010-07-16  7:10 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from burnus at gcc dot gnu dot org  2010-07-16 07:09 -------
(In reply to comment #9)
> (In reply to comment #6)
> > Please don't keep reopening this bug.
> > The symbols are weak undefs because libgfortran doesn't require (and shouldn't
> > require) libpthread, it is thread-safe only when libpthread is linked in.
> > 
> 
> After reviewing the thread (and recalling others along this line),
> Jakub, if you want to make the combination of -static -fopenmp
> a fatal error for gfortran, a patch is pre-approved.

I am against it - if you "properly" link it, e.g. using -Wl,--whole-archive or
with a POSIX Threads (pthread) library, which is linked with "ld -r", it works.

That's a similar issue to -m(no-)align-double: It leads to difficult to
understand crashes, but it is nontrivial to diagnose properly as there are
valid/working combinations - even though most combinations lead to crashes.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (9 preceding siblings ...)
  2010-07-16  7:10 ` burnus at gcc dot gnu dot org
@ 2010-07-16 14:48 ` kargl at gcc dot gnu dot org
  2010-07-19 10:25 ` victor dot pasko at gmail dot com
                   ` (2 subsequent siblings)
  13 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu dot org @ 2010-07-16 14:48 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #11 from kargl at gcc dot gnu dot org  2010-07-16 14:48 -------
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Please don't keep reopening this bug.
> > > The symbols are weak undefs because libgfortran doesn't require (and shouldn't
> > > require) libpthread, it is thread-safe only when libpthread is linked in.
> > > 
> > 
> > After reviewing the thread (and recalling others along this line),
> > Jakub, if you want to make the combination of -static -fopenmp
> > a fatal error for gfortran, a patch is pre-approved.
> 
> I am against it - if you "properly" link it, e.g. using -Wl,--whole-archive or
> with a POSIX Threads (pthread) library, which is linked with "ld -r", it works.

I don't see this in the information in the gfortran documentation.

> That's a similar issue to -m(no-)align-double: It leads to difficult to
> understand crashes, but it is nontrivial to diagnose properly as there are
> valid/working combinations - even though most combinations lead to crashes.

Well, I would like to disable the use of -malign-double on gfortran
as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (10 preceding siblings ...)
  2010-07-16 14:48 ` kargl at gcc dot gnu dot org
@ 2010-07-19 10:25 ` victor dot pasko at gmail dot com
  2010-07-19 16:53 ` jakub at gcc dot gnu dot org
  2010-07-20  6:19 ` victor dot pasko at gmail dot com
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-19 10:25 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #12 from victor dot pasko at gmail dot com  2010-07-19 10:25 -------
Isn't really difficult to fix that in libgfortran sources by using:

  if(pthread_cancel)
    {
       pthread_cancel(...);
    }

instead of just
    pthread_cancel(...);
as it is now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (11 preceding siblings ...)
  2010-07-19 10:25 ` victor dot pasko at gmail dot com
@ 2010-07-19 16:53 ` jakub at gcc dot gnu dot org
  2010-07-20  6:19 ` victor dot pasko at gmail dot com
  13 siblings, 0 replies; 15+ messages in thread
From: jakub at gcc dot gnu dot org @ 2010-07-19 16:53 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #13 from jakub at gcc dot gnu dot org  2010-07-19 16:52 -------
You clearly haven't looked at the code.
libgfortran uses gthr*.h macros/inlines for portability, and those test
pthread_cancel != NULL (using weak undef; test that for many different inlines,
see __gthread_active_p).  The problem is that if pthread_cancel is linked in
from libpthread.a, but some other pthread_* function is not, then it will crash
when calling that non-available function.
Testing all possible pthread_* functions that are ever mentioned in gthr*.h in
__gthread_active_p would be terrible for performance.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

* [Bug fortran/44927] static linkage with -lgomp fails on simple program
  2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
                   ` (12 preceding siblings ...)
  2010-07-19 16:53 ` jakub at gcc dot gnu dot org
@ 2010-07-20  6:19 ` victor dot pasko at gmail dot com
  13 siblings, 0 replies; 15+ messages in thread
From: victor dot pasko at gmail dot com @ 2010-07-20  6:19 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #14 from victor dot pasko at gmail dot com  2010-07-20 06:19 -------
(In reply to comment #13)
> You clearly haven't looked at the code.

Yes, I didn't look at libgfortran sources.
However, I am not sure about 'terrible performance' if just two instructions
(load and test) are added before every call to pthread-function.
Or remove weak pthread symbols there to have thread-safety by default.

But currently, namely crash occurs when -static -fopenmp are used :(
And in my opinion, it's not good to not allow using -static option in GNU
FORTRAN. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44927


^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2010-07-20  6:19 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-07-13  8:41 [Bug fortran/44927] New: static linkage with -lgomp fails on simple program victor dot pasko at gmail dot com
2010-07-13  9:22 ` [Bug fortran/44927] " jakub at gcc dot gnu dot org
2010-07-13  9:27 ` victor dot pasko at gmail dot com
2010-07-13 12:01 ` victor dot pasko at gmail dot com
2010-07-13 12:23 ` jakub at gcc dot gnu dot org
2010-07-13 12:37 ` victor dot pasko at gmail dot com
2010-07-13 17:08 ` jakub at gcc dot gnu dot org
2010-07-14 10:11 ` victor dot pasko at gmail dot com
2010-07-16  3:55 ` victor dot pasko at gmail dot com
2010-07-16  4:29 ` kargl at gcc dot gnu dot org
2010-07-16  7:10 ` burnus at gcc dot gnu dot org
2010-07-16 14:48 ` kargl at gcc dot gnu dot org
2010-07-19 10:25 ` victor dot pasko at gmail dot com
2010-07-19 16:53 ` jakub at gcc dot gnu dot org
2010-07-20  6:19 ` victor dot pasko at gmail dot com

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).