WIP: Fixed build issues under private linking for exported CMake targets. #126

Open
selk wants to merge 1 commits from fix/tdecore-CMakeLists into master
selk commented 1 year ago
Collaborator

Commit 158b6e1152413e4fa973b70b7469bb1f256a1f38[1] introduced a change in tdecore/CMakeLists.txt (lines 140~149) to make private linking for CMake targets. This leads to the following build errors[2] when I was trying to update from TDE 14.0.7 to TDE 14.0.9 here in Dragora GNU/Linux-Libre.

The proposed change accommodates lines to pass ${XCOMPOSITE_LIBRARIES} (-lXcomposite) when the presence of libXcomposite is detected, it also accommodates ${KDESVGICONS} to circumvent the build error, leaving these two variables out of the private linking statement.

[1] 158b6e1152
[2] http://ix.io/2OTG

Commit 158b6e1152413e4fa973b70b7469bb1f256a1f38[1] introduced a change in tdecore/CMakeLists.txt (lines 140~149) to make private linking for CMake targets. This leads to the following build errors[2] when I was trying to update from TDE 14.0.7 to TDE 14.0.9 here in Dragora GNU/Linux-Libre. The proposed change accommodates lines to pass ${XCOMPOSITE_LIBRARIES} (-lXcomposite) when the presence of libXcomposite is detected, it also accommodates ${KDESVGICONS} to circumvent the build error, leaving these two variables out of the private linking statement. [1] https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/commit/158b6e1152413e4fa973b70b7469bb1f256a1f38 [2] http://ix.io/2OTG
selk added 1 commit 1 year ago
e83bf5f7b2
Fixed build issues under private linking for exported CMake targets.
Owner

That doesn't seem like the right solution. For example, libltdlc is linked as static, for which it does not matter whether or not it is LINK_PRIVATE. Therefore, such a change concerning this library seems extremely suspicious.

When I look at your build log and compare it with mine, some libraries are completely missing in the list of linked libraries. For tdecore, -lICE -lSM -lz should be followed by ../libltdl/libltdlc.a svgicons/libkdesvgicons.a -lXcomposite -lidn -lutil, before -ludev, but they are not there. So it looks like something is wrong on your system and LINK_PRIVATE is not the real cause.

That doesn't seem like the right solution. For example, `libltdlc` is linked as static, for which it does not matter whether or not it is `LINK_PRIVATE`. Therefore, such a change concerning this library seems extremely suspicious. When I look at your build log and compare it with mine, some libraries are completely missing in the list of linked libraries. For tdecore, `-lICE -lSM -lz` should be followed by `../libltdl/libltdlc.a svgicons/libkdesvgicons.a -lXcomposite -lidn -lutil`, before `-ludev`, but they are not there. So it looks like something is wrong on your system and `LINK_PRIVATE` is not the real cause.
selk commented 1 year ago
Poster
Collaborator

Yes, it is strange. I'm still investigating, what strikes me is that under LINK_PRIVATE the value of ${XCOMPOSITE_LIBRARIES} does not appear, not appearing or at least not being visible - I don't see the value of -lXcomposite to the list of linked libraries, but leaving it as it "was" in TDE 14.0.7, it works.

It should be noted that I stayed on TDE version 14.0.7, which I managed to build for Dragora 3 (under development) which is based on Musl and LibreSSL, which I am trying to jump to the release of TDE 14.0.9.

I'll see what else I can gather...

Yes, it is strange. I'm still investigating, what strikes me is that under LINK_PRIVATE the value of ${XCOMPOSITE_LIBRARIES} does not appear, not appearing or at least not being visible - I don't see the value of -lXcomposite to the list of linked libraries, but leaving it as it "was" in TDE 14.0.7, it works. It should be noted that I stayed on TDE version 14.0.7, which I managed to build for Dragora 3 (under development) which is based on Musl and LibreSSL, which I am trying to jump to the release of TDE 14.0.9. I'll see what else I can gather...
selk commented 1 year ago
Poster
Collaborator

Very good news, I have basic TDE running in Dragora 3 -current :-D

To build tdelibs I have no choice but to apply the patch of this pull request, for some reason I think:

"LINK ltdlc-static" becomes public and so the links of those libraries are passed. This is the first case that I see in a source that this happens, also it would not explain the fact that you who have Glibc based systems do not see this or this problem does not appear, which is strange.

Also, I tried to compile tdelibs 14.0.8, but no luck, as the lines are set differently from tdelibs 14.0.7 (which did compile with the proposed Musl patches).

Well, the good news is that I was able to get around this obstacle by applying the patch, I also take this opportunity to report that after applying this patch and continue with tdebase 14.0.9, when building with Ninja there is an error that the header "kickerSettings.h" is missing (for some reason it does not generate it with Ninja). It would be nice if you can confirm this (let me know if you would like me to report on tdebase).

Anyway, I'm very happy as TDE loaded great!.

Very good news, I have basic TDE running in Dragora 3 -current :-D To build tdelibs I have no choice but to apply the patch of this pull request, for some reason I think: "LINK ltdlc-static" becomes public and so the links of those libraries are passed. This is the first case that I see in a source that this happens, also it would not explain the fact that you who have Glibc based systems do not see this or this problem does not appear, which is strange. Also, I tried to compile tdelibs 14.0.8, but no luck, as the lines are set differently from tdelibs 14.0.7 (which did compile with the proposed Musl patches). Well, the good news is that I was able to get around this obstacle by applying the patch, I also take this opportunity to report that after applying this patch and continue with tdebase 14.0.9, when building with Ninja there is an error that the header "kickerSettings.h" is missing (for some reason it does not generate it with Ninja). It would be nice if you can confirm this (let me know if you would like me to report on tdebase). Anyway, I'm very happy as TDE loaded great!.
Owner

Well, the good news is that I was able to get around this obstacle by applying the patch, I also take this opportunity to report that after applying this patch and continue with tdebase 14.0.9, when building with Ninja there is an error that the header "kickerSettings.h" is missing (for some reason it does not generate it with Ninja). It would be nice if you can confirm this (let me know if you would like me to report on tdebase).

On FreeBSD I build with Ninja and I didn't notice any problems. In any case there may be a suspicion that in the build log I see a double generation of kickerSettings.h:

[2357/4133] Generating kickerSettings.cpp, kickerSettings.h
[2396/4133] Generating kickerSettings.h

…so it looks like something that can be checked and possibly improved.

> Well, the good news is that I was able to get around this obstacle by applying the patch, I also take this opportunity to report that after applying this patch and continue with tdebase 14.0.9, when building with Ninja there is an error that the header "kickerSettings.h" is missing (for some reason it does not generate it with Ninja). It would be nice if you can confirm this (let me know if you would like me to report on tdebase). > On FreeBSD I build with Ninja and I didn't notice any problems. In any case there may be a suspicion that in the build log I see a double generation of kickerSettings.h: ``` [2357/4133] Generating kickerSettings.cpp, kickerSettings.h [2396/4133] Generating kickerSettings.h ``` …so it looks like something that can be checked and possibly improved.
selk commented 1 year ago
Poster
Collaborator

Wow...

For some reason I haven't seen this message, maybe is because I was expecting an email... Sorry for that.

About the error on tdebase, yes I cannot build using Ninja, instead I use GNU Make (v4.3) and it works. Feel free to report it on tdebase. Thank you!

Wow... For some reason I haven't seen this message, maybe is because I was expecting an email... Sorry for that. About the error on tdebase, yes I cannot build using Ninja, instead I use GNU Make (v4.3) and it works. Feel free to report it on tdebase. Thank you!
SlavekB changed title from Fixed build issues under private linking for exported CMake targets. to WIP: Fixed build issues under private linking for exported CMake targets. 7 months ago
SlavekB added the
PR/not-ok
PR/wip
labels 7 months ago
Owner

Because it needs more research and finding a problem somewhere else, I labeled it like WIP and NOT-OK.

Because it needs more research and finding a problem _somewhere else_, I labeled it like WIP and NOT-OK.
Owner

@selk could you also update us on this?

@selk could you also update us on this?
Poster
Collaborator

Hi guys,

@MicheleC Yes, I am still using the patch, as you can see here[1] and here[2].

[1] http://git.savannah.nongnu.org/cgit/dragora.git/tree/recipes/tde/tdebase/recipe
[2] http://git.savannah.nongnu.org/cgit/dragora.git/tree/patches/tdebase/kicker-clock-FTBFS.patch

Some time ago we agreed with @SlavekB that I was going to provide Dragora for testing, the problem is that I have not been able yet since I am still working on it, as to provide a more complete ISO (which is what most users expect). If you can and have time, I provide instructions to build Dragora from scratch, and then create an ISO (snapshot)[3].

[3] https://notabug.org/dragora/dragora/src/master/CHEATSHEET.md

Anyway I'm going and I'm with Trinity, so I'll look into what you guys are commenting on.

Hi guys, @MicheleC Yes, I am still using the patch, as you can see here[1] and here[2]. [1] http://git.savannah.nongnu.org/cgit/dragora.git/tree/recipes/tde/tdebase/recipe [2] http://git.savannah.nongnu.org/cgit/dragora.git/tree/patches/tdebase/kicker-clock-FTBFS.patch Some time ago we agreed with @SlavekB that I was going to provide Dragora for testing, the problem is that I have not been able yet since I am still working on it, as to provide a more complete ISO (which is what most users expect). If you can and have time, I provide instructions to build Dragora from scratch, and then create an ISO (snapshot)[3]. [3] https://notabug.org/dragora/dragora/src/master/CHEATSHEET.md Anyway I'm going and I'm with Trinity, so I'll look into what you guys are commenting on.
Owner

@MicheleC Yes, I am still using the patch, as you can see here[1] and here[2].

I am a bit confused. Is the patch good as is? Or does it need more work?

> @MicheleC Yes, I am still using the patch, as you can see here[1] and here[2]. I am a bit confused. Is the patch good as is? Or does it need more work?
Owner

@MicheleC Yes, I am still using the patch, as you can see here[1] and here[2].

I am a bit confused. Is the patch good as is? Or does it need more work?

See my first comment. Patch definitely does not seem good. This is a workaround around something weird that occurs in Dragora. Therefore, it needs further research.

> > @MicheleC Yes, I am still using the patch, as you can see here[1] and here[2]. > > I am a bit confused. Is the patch good as is? Or does it need more work? See my [first comment](issues/126#issuecomment-11096). Patch definitely does not seem good. This is a workaround around _something weird_ that occurs in Dragora. Therefore, it needs further research.
Owner

Ok, thanks @SlavekB for clarifying that.

Ok, thanks @SlavekB for clarifying that.
This pull request has changes conflicting with the target branch.
tdecore/CMakeLists.txt
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.