Как я могу исправить странные ошибки компоновщика динамических c символов, отличных от ascii, при отладке ржавчины с помощью clion?

Question

У меня сейчас эта проблема, которая началась через несколько недель после go, а затем исчезла по непонятной причине, так как она только что вернулась.

Я использовал стабильную версию инструментария ржавчины 1.40.0. один из моих коллег изменил код, в котором была задействована функция 1.43.1, поэтому мне пришлось выполнить обновление. Как только я это сделал и все перестроил, я начал получать эту ошибку при попытке отладки в clion:

/home/smark/git/target/debug/client: relocation error: /home/smark/git/target/debug/client: symbol $�H� version OPENSSL_1_1_0 not defined in file libcrypto.so.1.1 with link time reference

Я увидел ссылку в инструментальной цепочке версии 1.43.1, в которой говорилось: «OpenSSL обновлен до версии 1.1. .1g "так что я решил, что это может быть оно. Я понизился до 1.40.0, и отладчик заработал. Мой коллега сказал, что я не могу запускать версии позади всех, поэтому я снова обновился. также в это время был обновлен плагин rust для clion, и на этот раз, когда я попытался отладить его, я не получил сообщение об ошибке при запуске отладки в clion. Итак, я предполагаю, что это была ошибка в плагине clion, вызванная обновлением инструментальной цепочки ржавчины.

Все было хорошо, до сегодняшнего дня, когда это начало повторяться.

Та же ошибка, я этого не сделал. 'не обновляю какую-либо цепочку инструментов или плагин clion rust.

но теперь, вдобавок, я также получаю эту ошибку при попытке отладки другого двоичного файла:

/home/smark/git/target/debug/testreadcache: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_�.3.2' not found (required by /home/smark/git/target/debug/testreadcache)
/home/smark/git/target/debug/testreadcache: /lib/x86_64-linux-gnu/libgcc_s.so.1: version `GCC_�.2.0' not found (required by /home/smark/git/target/debug/testreadcache)
/home/smark/git/target/debug/testreadcache: /lib/x86_64-linux-gnu/libpthread.so.0: version `GLIBC_�.3.2' not found (required by /home/smark/git/target/debug/testreadcache)

Эти файлы .so существуют в указанное место, но я предполагаю, что что-то в номере искаженной версии приводит к его сбою.

В любом случае, я полагаюсь на отладчик для выполнения моей работы, и я не знаю, с чего начать искать, чтобы исправить это . Я чищу и перестраиваю с нуля, перезагружаюсь, перезапускаю ide, понятия не имею, что еще попробовать.

программа будет запускаться из командной строки, и она будет запускаться в gdb из командной строки, только не в клионе.

Есть предложения? Кто-нибудь видел такое раньше?

Answer 1

Так что если до этого я не был настоящим ненавистником ржавчины, то я им стал. : -)

Думаю, я наконец понял это, и я не могу представить, что я единственный человек, у которого есть эта проблема, так что если кто-то еще это сделает, может быть, это может помочь ... пожалуйста, присоединяйтесь ко мне борьба за улучшение программного обеспечения и недопустимость полностью сломанного программного обеспечения, такого как существующие инструменты для ржавчины ...

Я добавил это в файл go .toml в root моего проекта (это работает только здесь это не специфика проекта c)

# avoid any optimization
[profile.dev]
incremental = false
codegen-units = 1
lto = "off"

Можно подумать, что отладка не будет оптимизирована, но это явно так, и в некоторых случаях на linux будет физически разделаться двоичный файл. Я предполагаю, что это lto, и я уверен, что это проблема llvm, а не специфика ржавчины c, но опять же, если бы я был плотником, мне было бы все равно, почему мой молот сломан или кто его спроектировал или построил Плохо, я бы просто хотел, чтобы мой молот работал, чтобы я мог выполнять работу и не тратить бесконечные часы на борьбу, чтобы заставить мой молот работать.

Надеюсь, это кому-то поможет.

И заранее спасибо тому, кто считает нужным отредактировать этот пост, чтобы он не кипел от гнева. По крайней мере, не удаляйте полезную часть ответа, чтобы, может быть, кому-то еще не пришлось страдать, как я.