[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #36 from Dominique d'Humieres --- > Well... if I can't confirm it myself, and I can't put it in SUSPENDED, > and I can't mark it as RESOLVED... I guess I'll assign it to you then. An alternative would be to move the component from 'fortran' to 'target'.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 Eric Gallager changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |urbanjost at comcast dot net --- Comment #35 from Eric Gallager --- (In reply to urbanjost from comment #34) > It still occurs with Cygwin 2.8.2, which comes with gfortran 5.4.0, which is > the latest version of CygWin, if that is of any help. > > -Original Message- > From: dominiq at lps dot ens.fr [mailto:gcc-bugzi...@gcc.gnu.org] > Sent: Sunday, August 13, 2017 6:00 AM > To: urbanj...@comcast.net > Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not > loading from library > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 > > --- Comment #34 from Dominique d'Humieres --- > > So... what should we do with this bug then? I'm trying to move it out > > of the WAITING queue. Change to SUSPENDED? > > I am afraid that SUSPENDED is some kind of black hole for problems waiting > committee clarification. Here we are still waiting an answer from CygWin > users if it is still present with recent releases. > > -- > You are receiving this mail because: > You reported the bug. Well... if I can't confirm it myself, and I can't put it in SUSPENDED, and I can't mark it as RESOLVED... I guess I'll assign it to you then.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #34 from urbanjost at comcast dot net --- It still occurs with Cygwin 2.8.2, which comes with gfortran 5.4.0, which is the latest version of CygWin, if that is of any help. -Original Message- From: dominiq at lps dot ens.fr [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Sunday, August 13, 2017 6:00 AM To: urbanj...@comcast.net Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #34 from Dominique d'Humieres --- > So... what should we do with this bug then? I'm trying to move it out > of the WAITING queue. Change to SUSPENDED? I am afraid that SUSPENDED is some kind of black hole for problems waiting committee clarification. Here we are still waiting an answer from CygWin users if it is still present with recent releases. -- You are receiving this mail because: You reported the bug.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #34 from Dominique d'Humieres --- > So... what should we do with this bug then? I'm trying to move it out > of the WAITING queue. Change to SUSPENDED? I am afraid that SUSPENDED is some kind of black hole for problems waiting committee clarification. Here we are still waiting an answer from CygWin users if it is still present with recent releases.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #33 from Eric Gallager --- (In reply to Jerry DeLisle from comment #32) > (In reply to Eric Gallager from comment #30) > > (In reply to Jerry DeLisle from comment #29) > > > I happened to just get Cygwin installed and running on my Windows box. > > > Let > > > me run some tests and see if I can understand this. > > > > Did you ever do this? > > Nope, general life interference. So... what should we do with this bug then? I'm trying to move it out of the WAITING queue. Change to SUSPENDED?
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #32 from Jerry DeLisle --- (In reply to Eric Gallager from comment #30) > (In reply to Jerry DeLisle from comment #29) > > I happened to just get Cygwin installed and running on my Windows box. Let > > me run some tests and see if I can understand this. > > Did you ever do this? Nope, general life interference.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #31 from urbanjost at comcast dot net --- It may be of interest that the original application where this was encountered was changed to use modules, which I have had no similar problem with on Cygwin; but that the bug1.sh attachment still fails using gfortran 5.4.0 on Cygwin 2.7.0. Over the intervening time we found that the EXTERNAL statement was required on several other PEs (Programming Environments). So it seems the explicit EXTERNAL statement was used as a flag to scan and use the libraries listed on the loads or to insert some type of work-around. I would suggest any QA of a solution also test using shared libraries where supported, as another compiler did not have this issue with static libraries but had what manifested as the same symptoms when using shared libraries (since fixed). AThe Fortran standard gives some contrary indications (as I see it) on what external BLOCK_DATA_NAME means. Section 12.4.3.5 implies to me that if a matching BLOCKDATA name is not found at load time that an error should occur (which implies it should be searched for in the files presented to the loader); and that is what I have seen with other compilers/loaders. 12.4.3.5 EXTERNAL statement 1 An EXTERNAL statement specifies the EXTERNAL attribute (5.3.9) for a list of names. R1210 external-stmtis EXTERNAL [ :: ] external-name-list 2 The appearance of the name of a block data program unit in an EXTERNAL statement confirms that the block data program unit is a part of the program. But then a note in the standard gives the impression a plain BLOCK DATA does not by itself imply much: C.8.1 Main program and block data program unit (11.1, 11.3) 1 The name of the main program or of a block data program unit has no explicit use within the Fortran language. It is available for documentation and for possible use by a processor. To me, this explains why some compilers/loaders only work when there is an explicit EXTERNAL statement (C.8.1 is only talking about the name in the declaration of the BLOCK DATA; not in an EXTERNAL statement). Some old CDC and old CRAY Fortran 77 documentation (not current CRAY documents -- this was from around the time the XMP came out) explicitly stated that to ensure a BLOCK DATA is loaded when the use and declaration are not in the same file that the EXTERNAL statement was required; but I couldn't find anything else that was that clear about the issue. s regards the Fortran standard and why I think it does say this should work (aside from the fact it appears to work everywhere else I tried) ... I think I can summarize that by saying it is as clear as mud, but if it doesn't mean that what else would "external BLOCK_DATA_NAME" mean?
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #30 from Eric Gallager --- (In reply to Jerry DeLisle from comment #29) > I happened to just get Cygwin installed and running on my Windows box. Let > me run some tests and see if I can understand this. Did you ever do this?
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 Jerry DeLisle changed: What|Removed |Added Status|RESOLVED|WAITING CC||jvdelisle at gcc dot gnu.org Resolution|FIXED |--- --- Comment #29 from Jerry DeLisle --- I happened to just get Cygwin installed and running on my Windows box. Let me run some tests and see if I can understand this.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #28 from urbanjost at comcast dot net --- This is still a problem with Cygwin 2.2.1 and gfortran 4.9.3 $ cygcheck --version cygcheck (cygwin) 2.2.1 System Checker for Cygwie $ gfortran --version GNU Fortran (GCC) 4.9.3 $ bash bug1.sh ar: creating libex.a COMPILER gfortran BAD LOAD ix2(4)= -Original Message- From: fxcoudert at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Saturday, September 12, 2015 7:20 AM To: urbanj...@comcast.net Subject: [Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 --- Comment #27 from Dominique d'Humieres --- > Is it still true on recent versions of Cygwin (it has been fixed on darwin > since darwin10, see pr34136)? Ping! Without answer I'll close this PR as FIXED.
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #26 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is it still true on recent versions of Cygwin (it has been fixed on darwin since darwin10, see pr34136)?
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #24 from kargl at gcc dot gnu dot org 2010-01-16 23:18 --- Fixed in trunk. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #25 from kargl at gcc dot gnu dot org 2010-01-16 23:47 --- Re-open. Sorry guys, wrong PR. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #21 from burnus at gcc dot gnu dot org 2010-01-05 14:46 --- (In reply to comment #20) Dave, do you know how to emit the forceload and just exactly what is this? g77 does it as shown in http://gcc.gnu.org/viewcvs/branches/gcc-3_4-branch/gcc/f/com.c?view=markup -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #22 from ian at airs dot com 2010-01-05 16:09 --- For ELF, when the GNU linker has seen a common symbol, and then sees that symbol in the archive map, it will look in the object to see whether the object defines the symbol (rather than simply providing another common definition). If the object does define the symbol, then it is pulled into the link. See http://sourceware.org/ml/binutils/1999-12/msg00015.html . This was done for compatibility with the SunOS and HP/UX linkers, but in retrospect I think it may have been a mistake. For the PE target used on cygwin, the GNU linker does not do this. It follows the simpler rule. For that matter, the gold linker also does not do this. So, yes, the linkers behave differently. If you need to provide a common definition, and you also need to force that common definition to pull in a definition from an archive, then the compiler should arrange for that to happen. The easy way is: whenever you have a definition, also define some other symbol. Whenever you have a common symbol, also include an undefined reference to that definition. -- ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #23 from dominiq at lps dot ens dot fr 2010-01-05 18:12 --- This looks like a duplicate of pr34136. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #11 from burnus at gcc dot gnu dot org 2010-01-04 09:44 --- Mark as new as Jerry has confirmed it. Jerry, do you see whether this is a regression? From comment 0: this worked in previous versions of gfortran It would be useful to know in which version it still worked. Does MinGW work? Christopher, Dave: Do you have an idea what goes wrong? -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||davek at gcc dot gnu dot ||org, cgf at gcc dot gnu dot ||org Status|WAITING |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|2010-01-04 03:25:21 |2010-01-04 09:44:03 date|| Summary|BLOCKDATA referenced in |[Cygwin] BLOCKDATA |EXTERNAL not loading from |referenced in EXTERNAL not |library |loading from library http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #12 from davek at gcc dot gnu dot org 2010-01-04 15:42 --- COMMON symbols don't cause members to be pulled in from library archives. You can omit -L. -lex from the final link altogether and get the same result: it's unused. So the reference from bug.o to _jindx2 doesn't cause the library archive member to be drawn into the final link. With g77, there's this additional undefined symbol _juinit2_ in bug.o, which is not common, and hence causes the libex.a(juinit2.o) member to be drawn into the final link, at which time the explicit definition of _jindx2 overrides the common definition. gfortran doesn't generate any reference to _juinit2_ when it is used to compile bug.f, so there is nothing left to pull the archive member into the final link. The reference to _juinit2_ that g77 generates while compiling bug.f but gfortran does not generate has a label associated with it that suggests very strongly that g77 was aware of the problem that common symbols don't pull in lib archive members and uses this reference to an associated non-common symbol deliberately to solve the problem: .file bug.f .data .align 4 ___g77_forceload_0.0: .long _juinit2_ The forceload bit seems highly suggestive. Does gfortran need to adopt this part of g77's mechanism? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #13 from dominiq at lps dot ens dot fr 2010-01-04 16:05 --- The test fails also on *-apple-darwin9, but not on x86_64-apple-darwin10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #14 from kargl at gcc dot gnu dot org 2010-01-04 16:13 --- (In reply to comment #12) COMMON symbols don't cause members to be pulled in from library archives. You can omit -L. -lex from the final link altogether and get the same result: it's unused. So the reference from bug.o to _jindx2 doesn't cause the library archive member to be drawn into the final link. Comment #1 seems to contradict your assertion here. To repeat, laptop:kargl[207] gfc4x -c a2.f laptop:kargl[208] ar -cru libex.a a2.o laptop:kargl[209] gfc4x -o z a1.f -L. -lex laptop:kargl[210] ./z chars=abcdeabcdeabcdeabcdeabcde *missingBlockData* loaded common block -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #15 from davek at gcc dot gnu dot org 2010-01-04 16:36 --- (In reply to comment #14) (In reply to comment #12) COMMON symbols don't cause members to be pulled in from library archives. You can omit -L. -lex from the final link altogether and get the same result: it's unused. So the reference from bug.o to _jindx2 doesn't cause the library archive member to be drawn into the final link. Comment #1 seems to contradict your assertion here. To repeat, laptop:kargl[207] gfc4x -c a2.f laptop:kargl[208] ar -cru libex.a a2.o laptop:kargl[209] gfc4x -o z a1.f -L. -lex laptop:kargl[210] ./z chars=abcdeabcdeabcdeabcdeabcde *missingBlockData* loaded common block I can't tell anything from that. What is gfc4x, and what are a1.f and a2.f? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #16 from kargl at gcc dot gnu dot org 2010-01-04 17:13 --- (In reply to comment #15) (In reply to comment #14) (In reply to comment #12) COMMON symbols don't cause members to be pulled in from library archives. You can omit -L. -lex from the final link altogether and get the same result: it's unused. So the reference from bug.o to _jindx2 doesn't cause the library archive member to be drawn into the final link. Comment #1 seems to contradict your assertion here. To repeat, laptop:kargl[207] gfc4x -c a2.f laptop:kargl[208] ar -cru libex.a a2.o laptop:kargl[209] gfc4x -o z a1.f -L. -lex laptop:kargl[210] ./z chars=abcdeabcdeabcdeabcdeabcde *missingBlockData* loaded common block I can't tell anything from that. What is gfc4x, and what are a1.f and a2.f? gfc4x is gfortran 4.5. a1.f is OP's main program with the character(len=20) replaced by character(len=5) to prevent screen wrap on output. a2.f is OP's block data file. laptop:kargl[205] cat a1.f a2.f ! ! File a1.f ! program missingBlockData external juinit2 character chars(5)*(5) common /qindex2/chars save /qindex2/ write(*,*)'chars=',chars if(chars(5).ne.'abcde')then write(*,*)'*missingBlockData* E-R-R-O-R: bad load' else write(*,*)'*missingBlockData* loaded common block' endif end ! ! File a2.f ! block data juinit2 character chars(5)*(5) common /qindex2/chars save /qindex2/ data chars/5*'abcde'/ end You made an unmerited assertion that COMMON symbols don't cause members to be pulled in from library archives. I've shown the counter example. This appears to be linker issue on cygwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #17 from davek at gcc dot gnu dot org 2010-01-04 18:05 --- (In reply to comment #16) You made an unmerited assertion that COMMON symbols don't cause members to be pulled in from library archives. I've shown the counter example. On what platform? This appears to be linker issue on cygwin. It appears to be the entirely correct behaviour of the linker on PE-COFF platforms; I don't know about ELF platforms, which may well behave differently. Why do you supposed the forceload mechanism existed in g77 if not to allow the compiler to generate code that worked regardless of the target object format? See here: http://www.airs.com/blog/archives/48 In general the linker will not include archives if they provide a definition for a common symbol. Isn't that what's going on here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #18 from davek at gcc dot gnu dot org 2010-01-04 18:06 --- http://sources.redhat.com/bugzilla/show_bug.cgi?id=1811 also looks pertinent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #19 from kargl at gcc dot gnu dot org 2010-01-04 18:56 --- (In reply to comment #17) (In reply to comment #16) You made an unmerited assertion that COMMON symbols don't cause members to be pulled in from library archives. I've shown the counter example. On what platform? FreeBSD. Yes, it's an ELF platform. For the record, the behavior as I've shown occurs with GNU ld. % ld --version GNU ld version 2.15 [FreeBSD] 2004-05-23 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
[Bug fortran/42568] [Cygwin] BLOCKDATA referenced in EXTERNAL not loading from library
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2010-01-05 03:01 --- I have read through the links given by Dave. My take is that we have some implementation dependent, non portable, behaviour in linkers. Now that we know we have this inconsistency, the question is do we want to fix this with a work around in gfortran? From my read, there are situations where this is not desired behaviour. Obviously linux/Gnu is doing it. If so, exactly how is this done? Should it be handled by Cygwin? (by the linker?) Dave, do you know how to emit the forceload and just exactly what is this? What to do? and who? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42568
