-
Notifications
You must be signed in to change notification settings - Fork 989
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
Undefined references when building TigerVNC server #1691
Comments
Odd. It seems like librdr and libos were omitted from the link line. Can you run |
Heres the output:
|
Something is wrong there. This is the output when I run it on my Fedora 38 here:
As you can note here, the TigerVNC libraries (e.g. What does your
|
My file Your file includes these additional flags under
|
Tested building again from the start, but with the following cmake (had to install a few more build deps): Also noticed that I used some bad paths in the configure step, mainly using Unfortunately, I'm still getting the same error. Error output
My new linkline still only contains librdr.la twice, while your linkline contains it 3 times.
My
I got a warning when running
|
No, I don't think any of those flags are relevant here, unfortunately. |
I managed to build TigerVNC when adding a slash (/) to the end of my TIGERVNC_BUILDDIR path. Below are the lines I used, but This line builds successfully: This line gives build errors: Adding a slash to TIGERVNC_SRCDIR did not seem to have an impact. Either way, the building should be more robust than crashing on a missed slashed, I'll see if I can find the underlying reason for this behaviour. |
That is extremely odd. I don't have a slash in my builds here. And the automated builds here on GitHub also lack that slash. |
Is it possible that the slash only makes a difference in out-of-tree build, and not in in-tree builds? |
That, unfortunately, doesn't seem to be it. I have the same setup here. :/ |
Somewhat good news. I was able to reproduce the issue by tweaking the builds here: https://github.com/CendioOssman/tigervnc/actions/runs/7196969468/job/19603024854 |
Again, it has something to do with how the directories are specified. Works:
Broken:
|
You saved me. |
The circular dependencies [root@localhost vnc]# grep dependency_libs /root/workstation/tigervnc/build/common/network/libnetwork.la
dependency_libs=' /root/workstation/tigervnc/build/common/os/libos.la /root/workstation/tigervnc/build/common/rdr/librdr.la /root/workstation/tigervnc/build/common/rfb/librfb.la'
[root@localhost vnc]# grep dependency_libs /root/workstation/tigervnc/build/common/os/libos.la
dependency_libs=' /root/workstation/tigervnc/build/common/rdr/librdr.la -L/usr/lib64 -lpthread'
[root@localhost vnc]# grep dependency_libs /root/workstation/tigervnc/build/common/rdr/librdr.la
dependency_libs=' -L/usr/lib64 -lz /root/workstation/tigervnc/build/common/os/libos.la /root/workstation/tigervnc/build/common/rfb/librfb.la -L/usr/lib64 -lgnutls -L/usr/lib64 -lnettle'
[root@localhost vnc]# grep dependency_libs /root/workstation/tigervnc/build/common/rfb/librfb.la
dependency_libs=' /root/workstation/tigervnc/build/common/os/libos.la /root/workstation/tigervnc/build/common/rdr/librdr.la /root/workstation/tigervnc/build/common/network/libnetwork.la -L/usr/lib64 -ljpeg -L/usr/lib64 -lpixman-1 -L/usr/lib64 -lavcodec -L/usr/lib64 -lavutil -L/usr/lib64 -lswscale -L/usr/lib64 -lpam -L/usr/lib64 -lgnutls -L/usr/lib64 -lhogweed -L/usr/lib64 -lnettle -L/usr/lib64 -lgmp' |
If I run make command set TIGERVNC_BUILDDIR slash at the end. I get link command as below:
if no slash at the end, I get output as below:
From chatgpt:
|
It seems libtool doesn't support cyclic dependencies. It happens to work with that extra slash, simply because we trick libtool in to thinking they are different libraries and hence get added twice to the link line. Trying to reconstruct the loop using just libtool fails early because libtool fails to generate the We could consider adding more workarounds, but loops are extremely fragile. It is unknown how many times the loop needs to be specified to resolve all dependencies. It could easily break, even for CMake, if things get jumbled in the wrong way. I see a couple of proper fixes:
I think the last one is the only really robust method. Some variation on the first might be possible as an interim step to get the Xvnc builds more stable. |
I tried adding an intermediate library that bundles all the common libraries in to a single library, before linking that to Xvnc. It partly worked, but libtool isn't reliably propagating external dependencies to that new library. It seems to skip everything that is given with a file path. |
I've added a62b575 as a band-aid to keep things going for now. But we should look at a new structure to avoid the issue more robustly. |
This should hopefully be resolved now, via #1868. |
Describe the bug
When doing an out-of-tree build of the TigerVNC server on RHEL 8 I get the following errors (
os::Mutex
,rdr::Zlib...
,rdr::RandomStream
):Error output
To Reproduce
Steps to reproduce the behavior:
BUILDING.txt
cd tigervnc; mkdir build; cd build
cmake -G "Unix Makefiles" -DENABLE_H264=OFF -DENABLE_GNUTLS=OFF -DENABLE_NLS=OFF ..
make
make TIGERVNC_SRCDIR=/home/cendio/tigervnc TIGERVNC_BUILDDIR=/home/cendio/tigervnc/build
Expected behavior
Was expecting to be able to build.
Client (please complete the following information):
N/A
Server (please complete the following information):
N/A
Additional context
Found a similar problem when building on Windows in issue #981. That issue had no clear solution, but hinted towards multiple zlib:s on the system. This does not seem to be the case here.
The text was updated successfully, but these errors were encountered: