Hello devs,
In the past few months I had an issue on the TGW related to imlib while building the FreeBSD port. We had resolved it as if it was my error but it turns out I was not alone.
https://forums.freebsd.org/threads/make-error-code-1-when-compiling-trinity-...
Thankfully, they resolved the issue by using make -k (a flag I didnt know about) which allows you to continue building with errors. As I write this, Im in the process of doing the same.
Anyways, he also mentions that on the Gitea workspace imlib has not been updated in 2 years while other dependencies hosted on the TGW have. Is this something we're aware of? And better yet, I was told imlib2 is backwards compatible with imlib. Is there a reason we hold an older version of imlib than point to imlib2 which most distros and BSDs have? This may resolve more than just FreeBSD issues.
Thanks.
Anno domini 2022 Mon, 21 Mar 22:48:27 -0500 Hunter Ellett via tde-devels scripsit:
Hello devs,
In the past few months I had an issue on the TGW related to imlib while building the FreeBSD port. We had resolved it as if it was my error but it turns out I was not alone.
https://forums.freebsd.org/threads/make-error-code-1-when-compiling-trinity-...
Thankfully, they resolved the issue by using make -k (a flag I didnt know about) which allows you to continue building with errors. As I write this, Im in the process of doing the same.
Anyways, he also mentions that on the Gitea workspace imlib has not been updated in 2 years while other dependencies hosted on the TGW have. Is this something we're aware of? And better yet, I was told imlib2 is backwards compatible with imlib. Is there a reason we hold an older version of imlib than point to imlib2 which most distros and BSDs have? This may resolve more than just FreeBSD issues.
It's a pitty, but imlib2 is not 100% backwards compatible to imlib11. In fact they don't even have the same API calls nor the same functionality. E.g.: in the days when imlib2 "replaced" imlib1 I had issues with red/blue color channels swapped on RGBA images, which was architecture dependend so beeing a lot of fun to debug.
As the devuan/debian repository still has both versions I doubt that the surprise-moments of imlib2 are irioned out.
Nik
Thanks.
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
On March 22, 2022 3:41:55 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at wrote:
It's a pitty, but imlib2 is not 100% backwards compatible to imlib11. In fact they don't even have the same API calls nor the same functionality. E.g.: in the days when imlib2 "replaced" imlib1 I had issues with red/blue color channels swapped on RGBA images, which was architecture dependend so beeing a lot of fun to debug.
As the devuan/debian repository still has both versions I doubt that the surprise-moments of imlib2 are irioned out.
Oh, okay, my mistake. And I didn't know that about Debian/Devuan.
Anno domini 2022 Tue, 22 Mar 08:53:36 -0500 Hunter Ellett via tde-devels scripsit:
On March 22, 2022 3:41:55 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at wrote:
It's a pitty, but imlib2 is not 100% backwards compatible to imlib11. In fact they don't even have the same API calls nor the same functionality. E.g.: in the days when imlib2 "replaced" imlib1 I had issues with red/blue color channels swapped on RGBA images, which was architecture dependend so beeing a lot of fun to debug.
As the devuan/debian repository still has both versions I doubt that the surprise-moments of imlib2 are irioned out.
Oh, okay, my mistake. And I didn't know that about Debian/Devuan.
I just tried to comile TDE on my FreeBSD box and got stuck with imlib:
misc.c:126:7: warning: implicit declaration of function 'XShmQueryExtension' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryExtension(id->x.disp)) ^ misc.c:133:8: warning: implicit declaration of function 'XShmQueryVersion' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryVersion(id->x.disp, &maj, &min, &pm) == True) ^ misc.c:136:57: error: use of undeclared identifier 'ShmCompletion' id->x.shm_event = XShmGetEventBase(id->x.disp) + ShmCompletion;
[lots of errors of the same kind follow ...]
Do you know what's missing?
Nik
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
On March 22, 2022 8:57:29 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at wrote:
I just tried to comile TDE on my FreeBSD box and got stuck with imlib:
misc.c:126:7: warning: implicit declaration of function 'XShmQueryExtension' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryExtension(id->x.disp)) ^ misc.c:133:8: warning: implicit declaration of function 'XShmQueryVersion' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryVersion(id->x.disp, &maj, &min, &pm) == True) ^ misc.c:136:57: error: use of undeclared identifier 'ShmCompletion' id->x.shm_event = XShmGetEventBase(id->x.disp) + ShmCompletion;
[lots of errors of the same kind follow ...]
Do you know what's missing?
I'm not much of a developer myself, so no idea sadly. All I know is its much bigger of a problem than we thought because its halting more than one person from building the port. I actually just made it past that (imlib 1.9) but with "make -k install clean" in a clean right-after-install environment so if you want to try make -k its what the guy in the forum did. This skips errors though and it seems to be skipping a good bit on mine but otherwise I can't even install Trinity.
On March 22, 2022 9:17:43 AM CDT, Hunter Ellett via tde-devels I actually just made it past that (imlib 1.9) but with "make -k install clean" in a clean right-after-install environment Blah, don't listen to me. I misread it. It didn't install because of some error with pkg-static. Using make -r ended up fruitless. I'm going to have to do this the hard way and manually enter each directory.
Try to scan directory /usr/local/include. Probably something changed in Xext API (library libXext.so) desktop% nm -p /usr/lib/amd64/libXext.so.0.0.0|grep XShmQuery 000000000000ec43 T XShmQueryVersion 000000000000ebb7 T XShmQueryExtension (it's from my DilOS desktop zone)
Usualy, when some API changes, the old part closes by CPP directives, for example: #if defined(OLD_API) #warning Soon these functions will be removed void some_func(int); #endif /* OLD_API */
To make it available you should define OLD_API macro from this example, i.e.: cc -DOLD_API. Also you will see the warning: Soon these functions will be removed
On Tuesday 22 March 2022 17:17:43 Hunter Ellett via tde-devels wrote:
On March 22, 2022 8:57:29 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at
wrote:
I just tried to comile TDE on my FreeBSD box and got stuck with imlib:
misc.c:126:7: warning: implicit declaration of function 'XShmQueryExtension' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryExtension(id->x.disp)) ^ misc.c:133:8: warning: implicit declaration of function 'XShmQueryVersion' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryVersion(id->x.disp, &maj, &min, &pm) == True) ^ misc.c:136:57: error: use of undeclared identifier 'ShmCompletion' id->x.shm_event = XShmGetEventBase(id->x.disp) + ShmCompletion;
[lots of errors of the same kind follow ...]
Do you know what's missing?
I'm not much of a developer myself, so no idea sadly. All I know is its much bigger of a problem than we thought because its halting more than one person from building the port. I actually just made it past that (imlib 1.9) but with "make -k install clean" in a clean right-after-install environment so if you want to try make -k its what the guy in the forum did. This skips errors though and it seems to be skipping a good bit on mine but otherwise I can't even install Trinity.
Ok, it's HAVE_XSHM_H is not defined by "configure", so Xshm.h is not included. Need to look deeper :)
Nik
Anno domini 2022 Tue, 22 Mar 17:52:27 +0300 Denis Kozadaev scripsit:
Try to scan directory /usr/local/include. Probably something changed in Xext API (library libXext.so) desktop% nm -p /usr/lib/amd64/libXext.so.0.0.0|grep XShmQuery 000000000000ec43 T XShmQueryVersion 000000000000ebb7 T XShmQueryExtension (it's from my DilOS desktop zone)
Usualy, when some API changes, the old part closes by CPP directives, for example: #if defined(OLD_API) #warning Soon these functions will be removed void some_func(int); #endif /* OLD_API */
To make it available you should define OLD_API macro from this example, i.e.: cc -DOLD_API. Also you will see the warning: Soon these functions will be removed
On Tuesday 22 March 2022 17:17:43 Hunter Ellett via tde-devels wrote:
On March 22, 2022 8:57:29 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at
wrote:
I just tried to comile TDE on my FreeBSD box and got stuck with imlib:
misc.c:126:7: warning: implicit declaration of function 'XShmQueryExtension' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryExtension(id->x.disp)) ^ misc.c:133:8: warning: implicit declaration of function 'XShmQueryVersion' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryVersion(id->x.disp, &maj, &min, &pm) == True) ^ misc.c:136:57: error: use of undeclared identifier 'ShmCompletion' id->x.shm_event = XShmGetEventBase(id->x.disp) + ShmCompletion;
[lots of errors of the same kind follow ...]
Do you know what's missing?
I'm not much of a developer myself, so no idea sadly. All I know is its much bigger of a problem than we thought because its halting more than one person from building the port. I actually just made it past that (imlib 1.9) but with "make -k install clean" in a clean right-after-install environment so if you want to try make -k its what the guy in the forum did. This skips errors though and it seems to be skipping a good bit on mine but otherwise I can't even install Trinity.
tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
Then config.log has the answer.
On Tuesday 22 March 2022 18:31:08 Dr. Nikolaus Klepp wrote:
Ok, it's HAVE_XSHM_H is not defined by "configure", so Xshm.h is not included. Need to look deeper :)
Nik
Anno domini 2022 Tue, 22 Mar 17:52:27 +0300
Denis Kozadaev scripsit:
Try to scan directory /usr/local/include. Probably something changed in Xext API (library libXext.so) desktop% nm -p /usr/lib/amd64/libXext.so.0.0.0|grep XShmQuery 000000000000ec43 T XShmQueryVersion 000000000000ebb7 T XShmQueryExtension (it's from my DilOS desktop zone)
Usualy, when some API changes, the old part closes by CPP directives, for example: #if defined(OLD_API) #warning Soon these functions will be removed void some_func(int); #endif /* OLD_API */
To make it available you should define OLD_API macro from this example, i.e.: cc -DOLD_API. Also you will see the warning: Soon these functions will be removed
On Tuesday 22 March 2022 17:17:43 Hunter Ellett via tde-devels wrote:
On March 22, 2022 8:57:29 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at
wrote:
I just tried to comile TDE on my FreeBSD box and got stuck with imlib:
misc.c:126:7: warning: implicit declaration of function 'XShmQueryExtension' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryExtension(id->x.disp)) ^ misc.c:133:8: warning: implicit declaration of function 'XShmQueryVersion' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryVersion(id->x.disp, &maj, &min, &pm) == True) ^ misc.c:136:57: error: use of undeclared identifier 'ShmCompletion' id->x.shm_event = XShmGetEventBase(id->x.disp) + ShmCompletion;
[lots of errors of the same kind follow ...]
Do you know what's missing?
I'm not much of a developer myself, so no idea sadly. All I know is its much bigger of a problem than we thought because its halting more than one person from building the port. I actually just made it past that (imlib 1.9) but with "make -k install clean" in a clean right-after-install environment so if you want to try make -k its what the guy in the forum did. This skips errors though and it seems to be skipping a good bit on mine but otherwise I can't even install Trinity.
tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinityde sktop.org
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ____________________________________________________ tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydesk top.org
Dne út 22. března 2022 Dr. Nikolaus Klepp napsal(a):
Ok, it's HAVE_XSHM_H is not defined by "configure", so Xshm.h is not included. Need to look deeper :)
Nik
Hi Nik, Hunter,
on my test machine with FreeBSD is installed:
libXext-1.3.4,1
...and imlib build is successfull. Wherein libXext is installed from a binary package. What version do you have on your machine?
Cheers
Hi Slávek!
Anno domini 2022 Tue, 22 Mar 19:48:28 +0100 Slávek Banko scripsit:
Dne út 22. března 2022 Dr. Nikolaus Klepp napsal(a):
Ok, it's HAVE_XSHM_H is not defined by "configure", so Xshm.h is not included. Need to look deeper :)
Nik
Hi Nik, Hunter,
on my test machine with FreeBSD is installed:
libXext-1.3.4,1
...and imlib build is successfull. Wherein libXext is installed from a binary package. What version do you have on your machine?
Cheers
This is what's installed on my test system (clean install to virtual box). Almost packages are from binaries, exept:
"glib20" - This was the only paclage I had to build via portmaster. "*-trinity" - that's what I could build till imlib hit me.
I have attached: - make.log: Output from "make" - config.log: [...]/work/imlib_1.9.15/config.log - pkg.list: output from "pkg list"
What bothers me in config.log: configure:13423: checking X11/extensions/XShm.h configure:13438: result: no
But: $ pkg provides XShm.h Name : libXext-1.3.4,1 Desc : X11 Extension library Repo : FreeBSD Filename: usr/local/include/X11/extensions/XShm.h
$ pkg info | grep ibXext libXext-1.3.4,1 X11 Extension library
$ ll /usr/local/include/X11/extensions/XShm.h -rw-r--r-- 1 root wheel 3735 3 Feb. 02:15 /usr/local/include/X11/extensions/XShm.h
So I guess configure does not detect X11/extensions/XShm.h although it's there?
Nik
Hi Slávek!
Anno domini 2022 Tue, 22 Mar 19:48:28 +0100 Slávek Banko scripsit:
Dne út 22. března 2022 Dr. Nikolaus Klepp napsal(a):
Ok, it's HAVE_XSHM_H is not defined by "configure", so Xshm.h is not included. Need to look deeper :)
Nik
Hi Nik, Hunter,
on my test machine with FreeBSD is installed:
libXext-1.3.4,1
It's installed here, too.
...and imlib build is successfull. Wherein libXext is installed from a binary package. What version do you have on your machine?
Cheers
This is what's installed on my test system (clean install to virtual box). Almost packages are from binaries, exept:
"glib20" - This was the only paclage I had to build via portmaster. "*-trinity" - that's what I could build till imlib hit me.
I have attached: - make.log: Output from "make" - config.log: [...]/work/imlib_1.9.15/config.log - pkg.list: output from "pkg list" <<< Sorry, had to remove it, the can't post to list 'cause message to big >>>>
What bothers me in config.log: configure:13423: checking X11/extensions/XShm.h configure:13438: result: no
But: $ pkg provides XShm.h Name : libXext-1.3.4,1 Desc : X11 Extension library Repo : FreeBSD Filename: usr/local/include/X11/extensions/XShm.h
$ pkg info | grep ibXext libXext-1.3.4,1 X11 Extension library
$ ll /usr/local/include/X11/extensions/XShm.h -rw-r--r-- 1 root wheel 3735 3 Feb. 02:15 /usr/local/include/X11/extensions/XShm.h
So I guess configure does not detect X11/extensions/XShm.h although it's there?
Nik
Ok, this was a nobrainer:
There is a slightly wrong path in imlib/files/patch-search-system-include-for-xshm.diff. Please change "/usr/include/X11/extensions/XShm.h" to "/usr/local/include/X11/extensions/XShm.h" (note the /local/ part in it) and compile. This at least fixed the problem for my system :)
Nik
$ diff patch-search-system-include-for-xshm.diff~ patch-search-system-include-for-xshm.diff 8c8 < + if test -f "$x_includes/X11/extensions/XShm.h" || test -f "/usr/include/X11/extensions/XShm.h"; then ---
- if test -f "$x_includes/X11/extensions/XShm.h" || test -f "/usr/local/include/X11/extensions/XShm.h"; then
-- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...
Dne st 23. března 2022 Dr. Nikolaus Klepp napsal(a):
Ok, this was a nobrainer:
There is a slightly wrong path in imlib/files/patch-search-system-include-for-xshm.diff. Please change "/usr/include/X11/extensions/XShm.h" to "/usr/local/include/X11/extensions/XShm.h" (note the /local/ part in it) and compile. This at least fixed the problem for my system :)
Nik
$ diff patch-search-system-include-for-xshm.diff~ patch-search-system-include-for-xshm.diff 8c8 < + if test -f "$x_includes/X11/extensions/XShm.h" || test -f "/usr/include/X11/extensions/XShm.h"; then ---
- if test -f "$x_includes/X11/extensions/XShm.h" || test -f
"/usr/local/include/X11/extensions/XShm.h"; then
On my test system:
# ll /usr/local/include/X11/extensions/XShm.h -rw-r--r-- 1 root wheel 3735 Apr 8 2021 /usr/local/include/X11/extensions/XShm.h
And from my build.log:
checking sys/shm.h usability... yes checking sys/shm.h presence... yes checking for sys/shm.h... yes checking whether shmctl IPC_RMID allowes subsequent attaches... yes checking X11/extensions/XShm.h... yes checking for jpeg_destroy_decompress in -ljpeg... yes checking for jpeglib.h... yes
By visiting your make.log I see that the problem probably has the beginning already in the detection of Xorg. While on my system is:
checking for X... libraries /usr/local/lib, headers /usr/local/include
On your system is:
checking for X... libraries , headers
It is a question of whether it is the correct behavior or whether there should be listed paths, as you can see in my case. This is not specific to imlib - this is the result of the call AC_PATH_X macro from automake.
Cheers
Hi Slavek!
Anno domini 2022 Wed, 23 Mar 15:49:23 +0100 Slávek Banko scripsit:
Dne st 23. března 2022 Dr. Nikolaus Klepp napsal(a):
Ok, this was a nobrainer:
There is a slightly wrong path in imlib/files/patch-search-system-include-for-xshm.diff. Please change "/usr/include/X11/extensions/XShm.h" to "/usr/local/include/X11/extensions/XShm.h" (note the /local/ part in it) and compile. This at least fixed the problem for my system :)
Nik
$ diff patch-search-system-include-for-xshm.diff~ patch-search-system-include-for-xshm.diff 8c8 < + if test -f "$x_includes/X11/extensions/XShm.h" || test -f "/usr/include/X11/extensions/XShm.h"; then ---
- if test -f "$x_includes/X11/extensions/XShm.h" || test -f
"/usr/local/include/X11/extensions/XShm.h"; then
On my test system:
# ll /usr/local/include/X11/extensions/XShm.h -rw-r--r-- 1 root wheel 3735 Apr 8 2021 /usr/local/include/X11/extensions/XShm.h
And from my build.log:
checking sys/shm.h usability... yes checking sys/shm.h presence... yes checking for sys/shm.h... yes checking whether shmctl IPC_RMID allowes subsequent attaches... yes checking X11/extensions/XShm.h... yes checking for jpeg_destroy_decompress in -ljpeg... yes checking for jpeglib.h... yes
By visiting your make.log I see that the problem probably has the beginning already in the detection of Xorg. While on my system is:
checking for X... libraries /usr/local/lib, headers /usr/local/include
On your system is:
checking for X... libraries , headers
It is a question of whether it is the correct behavior or whether there should be listed paths, as you can see in my case. This is not specific to imlib - this is the result of the call AC_PATH_X macro from automake.
Cheers
As I did a clean install with minimal packages I assume that all users will run into this problem.
Could it be that you have a symlink from /usr/include/X11 to /usr/local/include/X11 ?
Nik
Dne st 23. března 2022 Dr. Nikolaus Klepp napsal(a):
Hi Slavek!
Anno domini 2022 Wed, 23 Mar 15:49:23 +0100
Slávek Banko scripsit:
Dne st 23. března 2022 Dr. Nikolaus Klepp napsal(a):
Ok, this was a nobrainer:
There is a slightly wrong path in imlib/files/patch-search-system-include-for-xshm.diff. Please change "/usr/include/X11/extensions/XShm.h" to "/usr/local/include/X11/extensions/XShm.h" (note the /local/ part in it) and compile. This at least fixed the problem for my system :)
Nik
$ diff patch-search-system-include-for-xshm.diff~ patch-search-system-include-for-xshm.diff 8c8 < + if test -f "$x_includes/X11/extensions/XShm.h" || test -f "/usr/include/X11/extensions/XShm.h"; then ---
- if test -f "$x_includes/X11/extensions/XShm.h" || test -f
"/usr/local/include/X11/extensions/XShm.h"; then
On my test system:
# ll /usr/local/include/X11/extensions/XShm.h -rw-r--r-- 1 root wheel 3735 Apr 8 2021 /usr/local/include/X11/extensions/XShm.h
And from my build.log:
checking sys/shm.h usability... yes checking sys/shm.h presence... yes checking for sys/shm.h... yes checking whether shmctl IPC_RMID allowes subsequent attaches... yes checking X11/extensions/XShm.h... yes checking for jpeg_destroy_decompress in -ljpeg... yes checking for jpeglib.h... yes
By visiting your make.log I see that the problem probably has the beginning already in the detection of Xorg. While on my system is:
checking for X... libraries /usr/local/lib, headers /usr/local/include
On your system is:
checking for X... libraries , headers
It is a question of whether it is the correct behavior or whether there should be listed paths, as you can see in my case. This is not specific to imlib - this is the result of the call AC_PATH_X macro from automake.
Cheers
As I did a clean install with minimal packages I assume that all users will run into this problem.
Could it be that you have a symlink from /usr/include/X11 to /usr/local/include/X11 ?
Nik
Hi Nik,
no, the symlink is not there.
As you can see, Xorg detection on my machine correctly detects "libraries /usr/local/lib, headers /usr/local/include" and therefore "X11/extensions/XShm.h" detection naturally succeeds in /usr/local/included => because the "x_includes" variable.
This returns us back to the fact that in your case AC_PATH_X does not fulfill the correct value into x_includes and x_libraries variables. And the question is why.
Cheers
Anno domini 2022 Wed, 23 Mar 17:36:35 +0100 Slávek Banko scripsit:
[..] no, the symlink is not there.
As you can see, Xorg detection on my machine correctly detects "libraries /usr/local/lib, headers /usr/local/include" and therefore "X11/extensions/XShm.h" detection naturally succeeds in /usr/local/included => because the "x_includes" variable.
This returns us back to the fact that in your case AC_PATH_X does not fulfill the correct value into x_includes and x_libraries variables. And the question is why.
Cheers
Sorry, that's where I don't have any clue. I never managed that automake/autoconf stuff. Anyway, changing the patch would work around the problem.
Nik
On March 22, 2022 9:52:27 AM CDT, Denis Kozadaev denis@tambov.ru wrote:
Try to scan directory /usr/local/include. Probably something changed in Xext API (library libXext.so) desktop% nm -p /usr/lib/amd64/libXext.so.0.0.0|grep XShmQuery 000000000000ec43 T XShmQueryVersion 000000000000ebb7 T XShmQueryExtension (it's from my DilOS desktop zone)
Usualy, when some API changes, the old part closes by CPP directives, for example: #if defined(OLD_API) #warning Soon these functions will be removed void some_func(int); #endif /* OLD_API */
To make it available you should define OLD_API macro from this example, i.e.: cc -DOLD_API. Also you will see the warning: Soon these functions will be removed
On Tuesday 22 March 2022 17:17:43 Hunter Ellett via tde-devels wrote:
On March 22, 2022 8:57:29 AM CDT, "Dr. Nikolaus Klepp" dr.klepp@gmx.at
wrote:
I just tried to comile TDE on my FreeBSD box and got stuck with imlib:
misc.c:126:7: warning: implicit declaration of function 'XShmQueryExtension' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryExtension(id->x.disp)) ^ misc.c:133:8: warning: implicit declaration of function 'XShmQueryVersion' is invalid in C99 [-Wimplicit-function-declaration] if (XShmQueryVersion(id->x.disp, &maj, &min, &pm) == True) ^ misc.c:136:57: error: use of undeclared identifier 'ShmCompletion' id->x.shm_event = XShmGetEventBase(id->x.disp) + ShmCompletion;
[lots of errors of the same kind follow ...]
Do you know what's missing?
I'm not much of a developer myself, so no idea sadly. All I know is its much bigger of a problem than we thought because its halting more than one person from building the port. I actually just made it past that (imlib 1.9) but with "make -k install clean" in a clean right-after-install environment so if you want to try make -k its what the guy in the forum did. This skips errors though and it seems to be skipping a good bit on mine but otherwise I can't even install Trinity.
tde-devels mailing list -- devels@trinitydesktop.org To unsubscribe send an email to devels-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/devels@trinitydeskt...
I just also got stuck on imlib when doing everything again more manually. I had similar errors but this did not work for me. I am going to skip tdegraphics until I can find out how to get imlib.
-
Denis Kozadaev -
Dr. Nikolaus Klepp -
Hunter Ellett -
Slávek Banko