Did we build 1.1 branch with sock on atlantis ? The build on atlantis fails, configure and make outputs are in atlantis:/sandbox/chan/mpich_work/build. If this is known, ignore this then. A.Chan ----- "mpich2" <[email protected]> wrote:
---------------------------------------------+------------------------------ Reporter: Eugene Loh <[email protected]> | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: mpich2 | Resolution: fixed Keywords: | ---------------------------------------------+------------------------------
Comment (by Anthony Chan):
I misunderstood your reply as well. Since we don't have access to any SUN's C compiler on AMD Linux box, Can you resend your configure and make outputs that were obtained on /tmp ? Since SUN's C compiler seems to be a stricter C compiler, some files may not be compiled ....
Thanks, A.Chan
----- "mpich2" <[email protected]> wrote:
---------------------------------------------+------------------------------
Reporter: Eugene Loh <[email protected]> | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: mpich2 | Resolution: fixed Keywords: |
---------------------------------------------+------------------------------
Comment (by Eugene Loh):
mpich2 wrote:
Comment (by Rajeev Thakur):
I thought you said that when you compiled on /tmp it worked.
No. You observed that the timestamps were all whacked up and suggested some sync'ed file system like /tmp. My point was that building
on
/tmp resolved the weird timestamp warnings, but they were never the point of my report. Those were just warnings that you observed as you looked through the log file.
What exactly doesn't work right now?
The same issue as in the original report. Namely, those "multiple definition" messages at the very end of the log file that indicated that the cpi.c example did not build.
I have this bad habit of repeating myself, but here goes.
I tried to "./configure; make". At the very end, the "make" tried to build the cpi.c example. It failed with those "multiple definition" messages, which were the subject of my problem report and the subject heading of this e-mail thread.
You (mpich2-maint) observed that there were many "future timestamp" warnings in the log and suggested building on a file system synced with the build node. I did so. That resolved the "future timestamp" messages but not the motivating problem ("multiple definition" and cpi.c not building).
Thanks for any further help. I'm asking around on other aliases and hope to get resolution from any of these resources.
-- Ticket URL: <https://trac.mcs.anl.gov/projects/mpich2/ticket/172#comment:>
-- Ticket URL: <https://trac.mcs.anl.gov/projects/mpich2/ticket/172#comment:>
That happens because you have configured with --enable-g I think. That probably sets #ifdef USE_DBG_LOGGING #define FLATTEN_DEBUG 1 #endif in flatten.c and expands #ifdef FLATTEN_DEBUG DBG_FPRINTF(stderr,"ADIOI_Flatten_datatype:: is_contig %#X\n",is_contig); to cause "/homes/chan/mpich_work/mpich2/src/mpi/romio/adio/common/flatten.c", line 48: undefined symbol: __FUNCTION__
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anthony Chan Sent: Monday, September 29, 2008 3:18 PM To: [email protected] Subject: [mpich2-core] Fwd: [mpich2-maint] #172: multiple definition?
Did we build 1.1 branch with sock on atlantis ? The build on atlantis fails, configure and make outputs are in atlantis:/sandbox/chan/mpich_work/build. If this is known, ignore this then.
A.Chan
----- "mpich2" <[email protected]> wrote:
---------------------------------------------+---------------- --------------
Reporter: Eugene Loh <[email protected]> | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: mpich2 | Resolution: fixed Keywords: |
---------------------------------------------+---------------- --------------
Comment (by Anthony Chan):
I misunderstood your reply as well. Since we don't have access to any SUN's C compiler on AMD Linux box, Can you resend your configure and make outputs that were obtained on /tmp ? Since SUN's C compiler seems to be a stricter C compiler, some files may not be compiled ....
Thanks, A.Chan
----- "mpich2" <[email protected]> wrote:
---------------------------------------------+---------------- --------------
Reporter: Eugene Loh <[email protected]> | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: mpich2 | Resolution: fixed Keywords: |
---------------------------------------------+---------------- --------------
Comment (by Eugene Loh):
mpich2 wrote:
Comment (by Rajeev Thakur):
I thought you said that when you compiled on /tmp it worked.
No. You observed that the timestamps were all whacked up and suggested some sync'ed file system like /tmp. My point was that building
on
/tmp resolved the weird timestamp warnings, but they were never the point of my report. Those were just warnings that you observed as you looked through the log file.
What exactly doesn't work right now?
The same issue as in the original report. Namely, those "multiple definition" messages at the very end of the log file that indicated that the cpi.c example did not build.
I have this bad habit of repeating myself, but here goes.
I tried to "./configure; make". At the very end, the "make" tried to build the cpi.c example. It failed with those "multiple definition" messages, which were the subject of my problem report and the subject heading of this e-mail thread.
You (mpich2-maint) observed that there were many "future timestamp" warnings in the log and suggested building on a file system synced with the build node. I did so. That resolved the "future timestamp" messages but not the motivating problem ("multiple definition" and cpi.c not building).
Thanks for any further help. I'm asking around on other aliases and hope to get resolution from any of these resources.
-- Ticket URL: <https://trac.mcs.anl.gov/projects/mpich2/ticket/172#comment:>
-- Ticket URL: <https://trac.mcs.anl.gov/projects/mpich2/ticket/172#comment:>
I don't believe __FUNCTION__ is part of the C language; it may be a nonportable gnuism . All instances should be removed before the release. In the MPICH2 code, we define FUNCNAME and FCNAME to provide portable access to the function name. Bill On Sep 29, 2008, at 4:34 PM, Rajeev Thakur wrote:
That happens because you have configured with --enable-g I think. That probably sets
#ifdef USE_DBG_LOGGING #define FLATTEN_DEBUG 1 #endif
in flatten.c and expands #ifdef FLATTEN_DEBUG DBG_FPRINTF(stderr,"ADIOI_Flatten_datatype:: is_contig %#X \n",is_contig);
to cause "/homes/chan/mpich_work/mpich2/src/mpi/romio/adio/common/flatten.c", line 48: undefined symbol: __FUNCTION__
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Anthony Chan Sent: Monday, September 29, 2008 3:18 PM To: [email protected] Subject: [mpich2-core] Fwd: [mpich2-maint] #172: multiple definition?
Did we build 1.1 branch with sock on atlantis ? The build on atlantis fails, configure and make outputs are in atlantis:/sandbox/chan/mpich_work/build. If this is known, ignore this then.
A.Chan
----- "mpich2" <[email protected]> wrote:
---------------------------------------------+---------------- --------------
Reporter: Eugene Loh <[email protected]> | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: mpich2 | Resolution: fixed Keywords: |
---------------------------------------------+---------------- --------------
Comment (by Anthony Chan):
I misunderstood your reply as well. Since we don't have access to any SUN's C compiler on AMD Linux box, Can you resend your configure and make outputs that were obtained on /tmp ? Since SUN's C compiler seems to be a stricter C compiler, some files may not be compiled ....
Thanks, A.Chan
----- "mpich2" <[email protected]> wrote:
---------------------------------------------+---------------- --------------
Reporter: Eugene Loh <[email protected]> | Owner: Type: bug | Status: closed Priority: major | Milestone: Component: mpich2 | Resolution: fixed Keywords: |
---------------------------------------------+---------------- --------------
Comment (by Eugene Loh):
mpich2 wrote:
Comment (by Rajeev Thakur):
I thought you said that when you compiled on /tmp it worked.
No. You observed that the timestamps were all whacked up and suggested some sync'ed file system like /tmp. My point was that building
on
/tmp resolved the weird timestamp warnings, but they were never the point of my report. Those were just warnings that you observed as you looked through the log file.
What exactly doesn't work right now?
The same issue as in the original report. Namely, those "multiple definition" messages at the very end of the log file that indicated that the cpi.c example did not build.
I have this bad habit of repeating myself, but here goes.
I tried to "./configure; make". At the very end, the "make" tried to build the cpi.c example. It failed with those "multiple definition" messages, which were the subject of my problem report and the subject heading of this e-mail thread.
You (mpich2-maint) observed that there were many "future timestamp" warnings in the log and suggested building on a file system synced with the build node. I did so. That resolved the "future timestamp" messages but not the motivating problem ("multiple definition" and cpi.c not building).
Thanks for any further help. I'm asking around on other aliases and hope to get resolution from any of these resources.
-- Ticket URL: <https://trac.mcs.anl.gov/projects/mpich2/ticket/172#comment:>
-- Ticket URL: <https://trac.mcs.anl.gov/projects/mpich2/ticket/172#comment:>
William Gropp Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign
On Tue, Sep 30, 2008 at 10:13:09PM -0500, William Gropp wrote:
I don't believe __FUNCTION__ is part of the C language; it may be a nonportable gnuism . All instances should be removed before the release. In the MPICH2 code, we define FUNCNAME and FCNAME to provide portable access to the function name.
__FUNCTION__ appears to be supported in a few compilers, but yes, it's not a standard. '__func__' is C99 (6.4.2.2 Predefined identifiers). Is that too new for some of the platforms we wish to support? ==rob -- Rob Latham Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF Argonne National Lab, IL USA B29D F333 664A 4280 315B
On Oct 1, 2008, at 7:57 AM, Robert Latham wrote:
On Tue, Sep 30, 2008 at 10:13:09PM -0500, William Gropp wrote:
I don't believe __FUNCTION__ is part of the C language; it may be a nonportable gnuism . All instances should be removed before the release. In the MPICH2 code, we define FUNCNAME and FCNAME to provide portable access to the function name.
__FUNCTION__ appears to be supported in a few compilers, but yes, it's not a standard. '__func__' is C99 (6.4.2.2 Predefined identifiers).
Is that too new for some of the platforms we wish to support?
Sadly it probably is. We have generally been targeting C89 with a few common bugs as our least common denominator. At this stage it's probably a lot safer to assume more of C99 than it was when the project started. However some of the compilers like the Sun compiler and the PGI compilers are broken in various ways wrt C99. If we didn't have the FUNCTION and FCNAME macros already then I'd say that we should just work around it via configure tests and some preprocessor tricks so that __func__ or __FUNCTION__ was just "" on the few broken compilers. But we do have the other macros and that's probably the right route to take here. -Dave
participants (5)
-
Anthony Chan -
Dave Goodell -
Rajeev Thakur -
Robert Latham -
William Gropp