Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#23713 closed defect (fixed)

openvrml +no_x11 has xorg dependencies

Reported by: braden@… Owned by: raphael-st (Raphael Straub)
Priority: Normal Milestone:
Component: ports Version: 1.8.2
Keywords: Cc:
Port: openvrml

Description

port install openvrml +no_x11 pulls in quite a few xorg dependencies, including xorg-libX11.

Change History (9)

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

Owner: changed from macports-tickets@… to raphael@…
Port: openvrml added

Please remember to fill in the Port field and cc the maintainer.

comment:2 Changed 14 years ago by raphael-st (Raphael Straub)

Resolution: fixed
Status: newclosed

Fixed in r63797, thanks!

comment:3 Changed 14 years ago by braden@…

I don't think requiring no_opengl is what you want to do here. OpenVRML's OpenGL renderer can be built against Apple's OpenGL; it does not require X11.

Unfortunately, the openvrml-xembed and openvrml-player bits do still require X11.

comment:4 in reply to:  3 ; Changed 14 years ago by raphael-st (Raphael Straub)

Resolution: fixed
Status: closedreopened

Replying to braden@…:

OpenVRML's OpenGL renderer can be built against Apple's OpenGL; it does not require X11.

I tried to do that, but I did not find out how to link against Apple's OpenGL while the mesa port is still active. Do you have any idea?

Unfortunately, the openvrml-xembed and openvrml-player bits do still require X11.

This is because gtkglext and libgnomeui use X11 in their default variant. Please make sure to install these ports (and all its dependencies) with variants +no_x11+quartz, e. g., by adding these variants to variants.conf.

comment:5 in reply to:  4 Changed 14 years ago by braden@…

Replying to raphael@…:

Replying to braden@…:

OpenVRML's OpenGL renderer can be built against Apple's OpenGL; it does not require X11.

I tried to do that, but I did not find out how to link against Apple's OpenGL while the mesa port is still active. Do you have any idea?

Argh. This appears to be the result of a bug I fixed upstream in autoconf-gl-macros, but forgot to push back down to OpenVRML before the 0.18.4 release. I'll do this and release 0.18.5.

Unfortunately, the openvrml-xembed and openvrml-player bits do still require X11.

This is because gtkglext and libgnomeui use X11 in their default variant. Please make sure to install these ports (and all its dependencies) with variants +no_x11+quartz, e. g., by adding these variants to variants.conf.

I haven't tried it; but because xembed/player rely on GtkPlug/GtkSocket, I don't expect them to work without X11.

comment:6 Changed 14 years ago by braden@…

0.18.5 has been released with some fixes to the AX_CHECK_GL macro. When I configure this release --without-x, it correctly applies -framework OpenGL instead of the conventional -lGL. Hopefully that addresses the problem here.

comment:7 in reply to:  6 Changed 14 years ago by raphael-st (Raphael Straub)

Resolution: fixed
Status: reopenedclosed

Replying to braden@…:

When I configure this release --without-x, it correctly applies -framework OpenGL instead of the conventional -lGL.

I cannot confirm this here. OpenVRML still links with mesa even when it is configured with --without-x. Nevertheless, I'll close this ticket, because I think I fixed the X11 dependencies and the port now ensures that mesa is inactive before building OpenVRML.

Fixed in r63871.

comment:8 Changed 14 years ago by braden@…

Okay, I see what's going on here. The configure test can't assume the libGL is linked to X11; so when it finds a usable libGL, it attempts to use it even if --without-x was passed.

I'm going to have to think about how to do this better. I'd prefer not to resurrect the --with-apple-opengl-framework option; but there might not be a better way. In the meantime, I think the port is doing the right thing now. Thanks!

comment:9 Changed 14 years ago by braden@…

I think I have a solution to this problem: check the found libGL for GLX functions (and fall back to -framework OpenGL if it has them and configure was run --without-x).

I've applied such a change to the macro here if you'd like to test it.

My impression is that there's a reasonable workaround for this, so I'm not going to rush out a(nother) release to address it. But I'll make sure this change finds its way into the next release.

Note: See TracTickets for help on using tickets.