Opened 22 months ago

Closed 12 days ago

#65464 closed defect (fixed)

gpac 2.0.0: error: use of undeclared identifier 'CLOCK_MONOTONIC'

Reported by: sambthompson (Sam Thompson) Owned by: mohd-akram (Mohamed Akram)
Priority: Normal Milestone:
Component: ports Version: 2.7.2
Keywords: elcapitan Cc: mascguy (Christopher Nielsen)
Port: gpac

Description

gpac fails to build on OS X 10.11:

quickjs/quickjs-libc.c:2058:5: warning: implicit declaration of function 'clock_gettime' is invalid in C99 [-Wimplicit-function-declaration]
:info:build     clock_gettime(CLOCK_MONOTONIC, &ts);
:info:build     ^
:info:build quickjs/quickjs-libc.c:2058:19: error: use of undeclared identifier 'CLOCK_MONOTONIC'
:info:build     clock_gettime(CLOCK_MONOTONIC, &ts);
:info:build                   ^
:info:build 1 warning and 1 error generated.

Presumably affects earlier versions of OS X; per #65124, Ryan Schmidt wrote:

clock_gettime and related identifiers were added in macOS 10.12. Consider including the legacy support portgroup which provides an implementation of clock_gettime for older systems.

Attachments (3)

main.log (493.8 KB) - added by sambthompson (Sam Thompson) 22 months ago.
main.2.log (503.9 KB) - added by sambthompson (Sam Thompson) 22 months ago.
Log after legacy support was added.
main.3.log (559.1 KB) - added by sambthompson (Sam Thompson) 22 months ago.
Repeated after port clean --all gpac and port -vt upgrade gpac

Download all attachments as: .zip

Change History (16)

Changed 22 months ago by sambthompson (Sam Thompson)

Attachment: main.log added

comment:1 Changed 22 months ago by mascguy (Christopher Nielsen)

Cc: mascguy added

comment:2 Changed 22 months ago by Christopher Nielsen <mascguy@…>

Resolution: fixed
Status: assignedclosed

In f2b7ed099f16c9585bf0f5d03f7278b0631f29cf/macports-ports (master):

gpac: use pg legacysupport for clock_gettime()
Fixes: #65464

comment:3 Changed 22 months ago by sambthompson (Sam Thompson)

Resolution: fixed
Status: closedreopened

Thanks, @mascguy, but still getting a build error here, this time from the linker:

:info:build Undefined symbols for architecture x86_64:
:info:build   "_clock_gettime", referenced from:
:info:build       _js_os_poll in quickjs-libc.o
:info:build       _js_os_setTimeout in quickjs-libc.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)

Tried port clean gpac to clean up prior build artifacts. Adding log.

Changed 22 months ago by sambthompson (Sam Thompson)

Attachment: main.2.log added

Log after legacy support was added.

Changed 22 months ago by sambthompson (Sam Thompson)

Attachment: main.3.log added

Repeated after port clean --all gpac and port -vt upgrade gpac

comment:4 Changed 22 months ago by sambthompson (Sam Thompson)

Maybe same cause as #65427; seems to be similar error.

comment:5 Changed 22 months ago by jmroot (Joshua Root)

Looks like the legacysupport flags need to be added in the configure args.

comment:6 Changed 22 months ago by sambthompson (Sam Thompson)

I note the fix to got in #65124 didn't add any flags?

comment:7 in reply to:  6 ; Changed 22 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to sambthompson:

Maybe same cause as #65427; seems to be similar error.

It is the "same cause" in that, as in #65427, this port is not honoring MacPorts LDFLAGS (irrespective of legacysupport: note how the -arch flag is missing on the link line too), but since each build system is unique, a unique solution will need to be developed for this port.

Replying to sambthompson:

I note the fix to got in #65124 didn't add any flags?

That's because got's build system is not identical to the snownews or gpac build systems. Different developers decided to do things different ways. Portfiles have to supply information to the different build systems in the ways they expect.

comment:8 in reply to:  7 Changed 22 months ago by sambthompson (Sam Thompson)

Thanks, Ryan;

Wondering if it's the presence of the configure.args affecting the flags in the portfile on lines 83-84:

configure.args      --cc="${configure.cc}" \
                    --cxx="${configure.cxx}" \
                    --extra-cflags="${configure.cc_archflags}" \
                    --extra-ldflags="${configure.ld_archflags}" \
                    --mandir=${prefix}/share/man \
                    --X11-path=${prefix} \
                    --disable-pulseaudio \

comment:9 Changed 22 months ago by mascguy (Christopher Nielsen)

Most of the time, legacysupport works without further changes, and didn't expect any issues. Sorry folks!

Looking at this now.

comment:10 Changed 22 months ago by mascguy (Christopher Nielsen)

Tried some quick, naive fixes, but no dice so far.

Need to dig into upstream's configure and build scripts, to better understand what's happening.

comment:11 Changed 18 months ago by erikbs

On Mac/Darwin, unlike other platforms, gpac overwrites the user-specified LDFLAGS, so the flags inserted by MacPorts to link legacy-support are never actually passed to the linker. On other platforms gpac’s flags are appended to LDFLAGS instead. Since there is nothing that suggests that this is intentional, I created a pull request on the gpac master repo to address this and also a pull request for the gpac Portfile so that we do not have to wait for the next version of gpac: https://github.com/macports/macports-ports/pull/16604

comment:12 in reply to:  11 Changed 15 months ago by sambthompson (Sam Thompson)

Replying to erikbs:

On Mac/Darwin, unlike other platforms, gpac overwrites the user-specified LDFLAGS, so the flags inserted by MacPorts to link legacy-support are never actually passed to the linker. On other platforms gpac’s flags are appended to LDFLAGS instead. Since there is nothing that suggests that this is intentional, I created a pull request on the gpac master repo to address this and also a pull request for the gpac Portfile so that we do not have to wait for the next version of gpac: https://github.com/macports/macports-ports/pull/16604

Thanks, erikbs! Both PRs have been accepted and a recent upgrade to gpac 2.2.0_0 seems to have gone fine. I think this is fixed now and can be closed.

comment:13 Changed 12 days ago by mohd-akram (Mohamed Akram)

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.