QtCreator internal error

,

PS: It’s my first English post, plz excuse my mistake :slight_smile:

Problem

fangyuan@fedora ~ [127]> qtcreator
qtcreator: symbol lookup error: /usr/bin/../lib64/qtcreator/libUtils.so.13: undefined symbol: _ZN19QAbstractFileEngine11setFileTimeERK9QDateTimeNS_8FileTimeE, version Qt_6.7_PRIVATE_API

2 Likes

From Proposed Common Issues to Ask Fedora

I can reproduce the error you see.
I have raised this bug: 2283847 – qtcreator cannot resolve sytmbol from libUtils.so.13 for the maintain to comment on the problem.

3 Likes

I get the same error when I try to launch QtCreator from the command-line (MATE Fedora 40)
qtcreator: symbol lookup error: /usr/bin/…/lib64/qtcreator/libUtils.so.13: undefined symbol: _ZN19QAbstractFileEngine11setFileTimeERK9QDateTimeNS_8FileTimeE, version Qt_6.7_PRIVATE_API.

Also, the QtCtreator desktop and Applications Panel shortcuts fail as well. Oddly enough QtDesigner still launches.

I reinstalled QtCreator via command-line and it still fails.

The fix for this being tested. See the bugzilla issue for details.

I can confirm that this bug is still present on Fedora 40 Workstation at the date of this comment.

If you need the fix now you can install the RPM that is in testing.

See FEDORA-2024-e8419f31ee — bugfix update for qt-creator — Fedora Updates System for the progress of the fix moving towards updates. My guess is that it will be in updates in a couple of days.

FYI there is always a delay from a new RPM being sumitted for release and it being part of fedora updates. This delay allows for testing.

Why isn’t this broken package rolled back until the testing is done?

Rolling back is often harder then rolling forward and also involves the same timed delay.

If you need the fix before its put in to updates you can install using the information in the bugzilla ticket.

I usually do this for any bug were I want the fix.

Isn’t this a major problem?
Rolling back broken updates and patches should be easy and immediate such that the production environment continues to be functional.

It happens that there are several easy workaround to this particular problem, but what if the update had brought bugs that broke more fundamental parts of the OS and there where no workarounds. How can it then be acceptable that rolling back updates isn’t easy and immediate?

In practice this is a rare occurance in my experience.

The user can always try a dnf downgrade to see if that helps.

That would be a massive failure of testing.
I’m not aware of that ever happending.