Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#28493 closed defect (fixed)

hdf5-18 1.8.6_1 build failure

Reported by: astrofitz (Michael Fitzgerald) Owned by: mamoll (Mark Moll)
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: Cc:
Port: hdf5-18

Description

I am encountering a build failure. This occurs while trying to build the file H5dbg.o, with the first error message "H5TSprivate.h:42: error: expected specifier-qualifier-list before 'CRITICAL_SECTION'" (see attached log).

Attachments (3)

main.log (19.6 KB) - added by astrofitz (Michael Fitzgerald) 14 years ago.
build log
main.2.log (2.0 MB) - added by mamoll (Mark Moll) 14 years ago.
mmoll-main.log
main.3.log (49.3 KB) - added by astrofitz (Michael Fitzgerald) 14 years ago.

Change History (9)

Changed 14 years ago by astrofitz (Michael Fitzgerald)

Attachment: main.log added

build log

comment:1 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)

Owner: changed from macports-tickets@… to mmoll@…

Changed 14 years ago by mamoll (Mark Moll)

Attachment: main.2.log added

mmoll-main.log

comment:2 Changed 14 years ago by mamoll (Mark Moll)

It works for me. There are small differences in how files are compiled. The H5dbg.c is compiled like so for you:

:info:build libtool: compile:  
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -DNDEBUG -UH5_DEBUG_API -I/opt/local/include -std=c99 -pedantic -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wfloat-equal -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -Wformat=2 -Wunreachable-code -Wendif-labels -Wdeclaration-after-statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -Wnonnull -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -Wvolatile-register-var -Wstrict-overflow -O3 -fomit-frame-pointer -finline-functions -pipe -O2 -arch x86_64 -MT H5dbg.lo -MD -MP -MF .deps/H5dbg.Tpo -c H5dbg.c  -fno-common -DPIC -o .libs/H5dbg.o

On my machine (OS X 10.6.6), it compiles like so:

:info:build /bin/sh ../libtool --tag=CC   --mode=compile 
/usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I.  -DNDEBUG -UH5_DEBUG_API -I/opt/local/include -std=c99 -pedantic -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wfloat-equal -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -Wformat=2 -Wunreachable-code -Wendif-labels -Wdeclaration-after-statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -Wnonnull -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -Wvolatile-register-var -Wstrict-overflow -O3 -fomit-frame-pointer -finline-functions -pipe -O2 -arch x86_64 -MT H5Fdbg.lo -MD -MP -MF .deps/H5Fdbg.Tpo -c -o H5Fdbg.lo H5Fdbg.c

What could be different between your setup and mine?

comment:3 Changed 14 years ago by jmroot (Joshua Root)

Everything before the build phase is missing from the reporter's log so it's hard to know. Does the build system perhaps re-libtoolize itself?

Changed 14 years ago by astrofitz (Michael Fitzgerald)

Attachment: main.3.log added

comment:4 Changed 14 years ago by mamoll (Mark Moll)

Maybe. How do I force this (if this is what it should be doing) or disable it (if it causing the compilation to fail)?

comment:5 Changed 14 years ago by mamoll (Mark Moll)

Resolution: fixed
Status: newclosed

It looks like the reporter had the threadsafe variant enabled. With this variant enabled, compilation fails for me, too, but in a different file with a different error. The release notes at http://www.hdfgroup.org/ftp/HDF5/current/src/hdf5-1.8.6-RELEASE.txt say that the thread-safe version is not supported on OS X. I'll remove this variant and close the ticket. If the reporter has this problem without the threadsafe variant, I'll reopen the ticket.

comment:6 Changed 14 years ago by astrofitz (Michael Fitzgerald)

I was indeed able to successfully build the port with the threadsafe option disabled. It may be splitting hairs, but the release notes suggest the threadsafe option on OSX is merely untested, rather than unsupported. Perhaps at this point it is an upstream problem.

Note: See TracTickets for help on using tickets.