Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

building on ubuntu linux 18.04 #6

Open
retostockli opened this issue Feb 21, 2020 · 6 comments
Open

building on ubuntu linux 18.04 #6

retostockli opened this issue Feb 21, 2020 · 6 comments

Comments

@retostockli
Copy link

I end up with the following GLXEWContext unknown type error when building:
In file included from ../src/glew_os.c:19:0:
../src/acfutils/glew_os.h:53:21: error: unknown type name ‘GLXEWContext’
extern THREAD_LOCAL GLXEWContext lacf_glxew_per_thread_ctx;

I am using the regular Ubuntuo GLEW implementation. headers are found. So I started to look about your patches. I see that you patch these for Mac:
ctx_funcs_2.patch
ctx_funcs_1.patch

Shouldn't they also be patched for linux?
Reto

@kukel
Copy link

kukel commented Sep 2, 2020

I got the same error and while playing with all sorts of things, it suddenly worked... So no idea what causes this (have no idea what fixed it). Lots of others things though like shapelib1.4.1 not compiling at all (1.5.0 does but has no ./configure where libacfutils currently depends on). Seems to depend on many old versions as it seems

@kukel
Copy link

kukel commented Sep 2, 2020

Currently starting from scratch to see how I can get it to work. shapelib 1.41 was not a problem, openal 1.19.1 was. And I am at the same problem. Cannot get it fixed (over two hours of trying)

Patching is not needed. One of the .h files that are included contains this type so I have no clue what the cause is (being a java developer myself)

Might be a stricter gcc...

My error is

GNU C99 (GCC) version 10.2.1 20200723 (Red Hat 10.2.1-1) (x86_64-redhat-linux)
        compiled by GNU C version 10.2.1 20200723 (Red Hat 10.2.1-1), GMP version 6.1.2, MPFR version 4.0.2-p9, MPC version 1.1.0, isl version isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f0854f6113f296a2ef10a437ae064ca7
In file included from ../src/glew_os.c:19:
../src/acfutils/glew_os.h:53:21: error: unknown type name ‘GLXEWContext’
   53 | extern THREAD_LOCAL GLXEWContext lacf_glxew_per_thread_ctx;
      |                     ^~~~~~~~~~~~
../src/acfutils/glew_os.h:55:15: error: unknown type name ‘GLXEWContext’
   55 | static inline GLXEWContext *
      |               ^~~~~~~~~~~~
../src/glew_os.c:22:14: error: unknown type name ‘GLXEWContext’
   22 | THREAD_LOCAL GLXEWContext lacf_glxew_per_thread_ctx;
      |

And I had to add

INCLUDEPATH += ../curl/libcurl-linux-64/include
INCLUDEPATH += ../libxml2/libxml2-linux-64/include/libxml2
INCLUDEPATH += ../cairo/cairo-linux-64/include/cairo
INCLUDEPATH += ../glew/glew-1.13.0-linux-64/include

to the qmake.pro file to get it prevent include errors. Maybe some libraries are already on his system so theses do not occur then.

@retostockli
Copy link
Author

The intention is a good one to ship acfutils with all dependencies and let the build system build all dependencies in one shot befor building the library itself. However, the complex build scripts then can cause a lot of trouble. I personally prefer packages which depend on the respective libraries of my OS. Of course, that might again cause versioning problems. I wish you good luck. With Ubuntu 18.04 all builds went through fine on my side.

@kukel
Copy link

kukel commented Sep 3, 2020

@retostockli : But did you actually solve the problem described above?

@kukel
Copy link

kukel commented Sep 3, 2020

Changing

DEFINES += GLEW_STATIC

to

DEFINES += GLEW_STATIC GLEW_MX

Solved this issue... Now the next one

Since I also needed to add glew to the include path, it might be the pkgconfig is not picked up correctly. Maybe the same for cairo etc

@kukel
Copy link

kukel commented Sep 3, 2020

I found the cause of this issue, at least on my side. It also allows to remove all the INCLUDEPATH entries I (thought I) needed. The cause was indeed in the pkgconfigs not being picked up since 1 failed all the next ones failed to hence needing the includes and the define. Once I fixed the typo (my own) in the pkg-config-deps all worked. The reason for the typo was that I needed to update openal-soft from 1.19.1 to 1.20.1 since the 1.19.1 version does not compile at all on fedora 32. Might be that some of the dependencies failed to compile so your pkg-config-deps also failed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants