glu again

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

glu again

chrysn
hi don, hello openscad developers,

following up on the "missing include on ubuntu precise and probably
fedora 16" thread, under some conditions i can't exactly pinpoint,
openscad builds fail on ubuntu precise[1]::

    objects/glview.o: In function `GLView::initializeGL()': /build/buildd/openscad-2011.12/src/glview.cc:285: undefined reference to `gluErrorString'

the problem seems to already have shown up in fedora 16, as these lines
in openscad.pro show::

    # Fedora Linux + DSO fix
    linux*:exists(/usr/lib64/libGLU*)|linux*:exists(/usr/lib/libGLU*) {
      LIBS += -lGLU
    }

glview.cc uses gluErrorString and gluLookAt -- why would we only link
against GLU under those conditions?

as to explain why the build process failed, i assume it has to do with
debian based distributions nowadays using architecture dependent library
paths (multiarch). we could use pkg-config to figure out where exactly
to look for libGLU, but i'd rather understand why -lGLU isn't used
unconditionally. don (you added it in b6a01a76b9), could you enlighten
me in that respect?

for the time being, my packages replace said block in openscad.pro with
an unconditional LIBS += -lGLU. thus, there are precise packages again.

regards
chrysn

[1] https://launchpadlibrarian.net/104895555/buildlog_ubuntu-precise-amd64.openscad_2011.12-2%2Bprecise1_FAILEDTOBUILD.txt.gz

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glu again

donbright
My strategy for the build script was that it should modify build flags
only if absolutely necessary, in order to prevent unpredictable
breakages on other platforms. For example, before my patch, there was
no explicit use of -lGLU at all in openscad.pro... i assume that up to
that point in history, the systems being used had automatically added
that flag for some reason (perhaps thru another library, perhaps
through qmake, i do not know)

Then I encountered a redhat system with this new DSO thing where you
need to add the flag explicitly, so i tried to make it only add the
flag when being built on that system that i had access to. I am not
sure if it would break older systems or cross-compiled systems, i was
just following a general principle to avoid adding explicit flags
unnecessarily.

I didn't know that pkgconfig could work with qmake, that sounds very
cool. An interesting point - there is apparently no 'glu' specific
flag code in the Cmake build of the test suite - i am curious as to
whether the cmake tests build works properly on the systems you are
seeing breakage on.... ? Thanks for looking into this.

DB

On Sat, May 12, 2012 at 7:50 AM, chrysn <[hidden email]> wrote:

> hi don, hello openscad developers,
>
> following up on the "missing include on ubuntu precise and probably
> fedora 16" thread, under some conditions i can't exactly pinpoint,
> openscad builds fail on ubuntu precise[1]::
>
>    objects/glview.o: In function `GLView::initializeGL()': /build/buildd/openscad-2011.12/src/glview.cc:285: undefined reference to `gluErrorString'
>
> the problem seems to already have shown up in fedora 16, as these lines
> in openscad.pro show::
>
>    # Fedora Linux + DSO fix
>    linux*:exists(/usr/lib64/libGLU*)|linux*:exists(/usr/lib/libGLU*) {
>      LIBS += -lGLU
>    }
>
> glview.cc uses gluErrorString and gluLookAt -- why would we only link
> against GLU under those conditions?
>
> as to explain why the build process failed, i assume it has to do with
> debian based distributions nowadays using architecture dependent library
> paths (multiarch). we could use pkg-config to figure out where exactly
> to look for libGLU, but i'd rather understand why -lGLU isn't used
> unconditionally. don (you added it in b6a01a76b9), could you enlighten
> me in that respect?
>
> for the time being, my packages replace said block in openscad.pro with
> an unconditional LIBS += -lGLU. thus, there are precise packages again.
>
> regards
> chrysn
>
> [1] https://launchpadlibrarian.net/104895555/buildlog_ubuntu-precise-amd64.openscad_2011.12-2%2Bprecise1_FAILEDTOBUILD.txt.gz
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad
>

Reply | Threaded
Open this post in threaded view
|

Re: glu again

chrysn
On Sat, May 12, 2012 at 08:43:22AM -0500, Don Bright wrote:
> My strategy for the build script was that it should modify build flags
> only if absolutely necessary, in order to prevent unpredictable
> breakages on other platforms. For example, before my patch, there was
> no explicit use of -lGLU at all in openscad.pro... i assume that up to
> that point in history, the systems being used had automatically added
> that flag for some reason (perhaps thru another library, perhaps
> through qmake, i do not know)

several glu symbols used to be exported with some other component
involved (maybe glew, i don't know). that's why we had 6a9b8a56c11. i
assume these are very much related, but am not sufficiently versed in
the ways of symbol resolution to say what exactly happened for sure.

> I didn't know that pkgconfig could work with qmake, that sounds very
> cool.

well, neither do i, but if qmake has some way of calling external
commands, it could use `pkg-config --variable libdir glu` to get the
path.

> An interesting point - there is apparently no 'glu' specific
> flag code in the Cmake build of the test suite - i am curious as to
> whether the cmake tests build works properly on the systems you are
> seeing breakage on.... ?

the test built fine on the ubuntu servers. i can't built it locally atm
to get verbosity (build failures with gcc 4.7), but
CMakeFiles/cgalcachetest.dir/build.make does include a line
cgalcachetest: /usr/lib/x86_64-linux-gnu/libGLU.so -- something in the
ctest build system seems to figure out glu matters.

regards
chrysn

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: glu again

kintel
Administrator
In reply to this post by chrysn
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

About the GLU issue:
GLU tends to be bundled into the GL library, but not on all systems.
This is basically why GLU is sometimes explicitly linked.
I guess qmake isn't too smart, so we need to handle it explicitly.

I can remember from my autotools days that there used to be a test for checking exactly this, to be able to link correctly.

 -Marius

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk+y/MUACgkQF4TaqdSZNKQKJwCffpSBszA+njv9x958PZf5CoSC
JF0AnjZufU4IH8rVIA5xQ6AHqtPT5SUW
=PxqN
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: glu again

kintel
Administrator
In reply to this post by chrysn
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 12, 2012, at 10:31 AM, chrysn wrote:
> well, neither do i, but if qmake has some way of calling external
> commands, it could use `pkg-config --variable libdir glu` to get the
> path.
>
That's doable on Linux and Mac but not Windows, unless run from a unix-style shell.
I think either of these should work:
VAR = $$system(cmd);
or
VAR = `cmd`

 -Marius

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAk+y/UsACgkQF4TaqdSZNKQ2kwCgxN21n+A+q99pWz5ihy7JNS6j
sEQAn0pHYgPhu4empDyImfESq30rUkWy
=t9sk
-----END PGP SIGNATURE-----

Reply | Threaded
Open this post in threaded view
|

Re: glu again

donbright
What are people's thoughts on scrapping qmake and just using Cmake for
the GUI build as well as the test build?

On Tue, May 15, 2012 at 8:05 PM, Marius Kintel <[hidden email]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On May 12, 2012, at 10:31 AM, chrysn wrote:
>> well, neither do i, but if qmake has some way of calling external
>> commands, it could use `pkg-config --variable libdir glu` to get the
>> path.
>>
> That's doable on Linux and Mac but not Windows, unless run from a unix-style shell.
> I think either of these should work:
> VAR = $$system(cmd);
> or
> VAR = `cmd`
>
>  -Marius
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iEYEARECAAYFAk+y/UsACgkQF4TaqdSZNKQ2kwCgxN21n+A+q99pWz5ihy7JNS6j
> sEQAn0pHYgPhu4empDyImfESq30rUkWy
> =t9sk
> -----END PGP SIGNATURE-----
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://rocklinux.net/mailman/listinfo/openscad

Reply | Threaded
Open this post in threaded view
|

Re: glu again

kintel
Administrator
On May 17, 2012, at 19:00 PM, Don Bright wrote:

> What are people's thoughts on scrapping qmake and just using Cmake for
> the GUI build as well as the test build?
>
Sure, if we can get a stable cmake setup, it would make sense.
I've learned not to underestimate what it takes to get cmake into production though ;)

 -Marius