Gcc x86 64 unknown linux gnu

Отладка ошибки » gcc: ошибка: x86 64-linux-gnu-gcc: нет такого файла или каталога»

Я пытаюсь построить: https://github.com/kanzure/nanoengineer

но похоже, что это ошибки на:

x86_64-linux-gnu-gcc наверняка существует в / usr / bin (это символическая ссылка), и цель определенно существует. Мне кажется, что Makefile был сгенерирован неправильно, возможно, есть флаг, который должен быть передан перед указанием x86_64-linux-gnu-gcc? Я также не уверен, что указывает x86_64-linux-gnu-gcc предполагается выполнять.

наконец, этот makefile был создан configure, поэтому, как только мы сузим причину ошибки, мне придется выяснить, какие файлы нужно изменить, чтобы исправить это. (Я сам парень типа CMake, но, конечно, я не выбирал систему сборки для этого проекта.) Моя ОС-Debian.

Я также пытался построить эту ветку: https://github.com/kanzure/nanoengineer/branches/kirka-updates

Если вы можете попробовать это постройте на вашей системе, я был бы очень признателен! Спасибо!

5 ответов

после изрядного количества работы я смог заставить его строить на Ubuntu 12.04 x86 и Debian 7.4 x86_64. Я написал руководство ниже. Можете ли вы попробовать следовать за ним, чтобы увидеть, решает ли он проблему?

если не Пожалуйста, дайте мне знать, где вы застряли.

Установить Общие Зависимости

Установить NumArray 1.5.2

Установите Цифровой 23.8

установить HDF5 1.6.5

Установить Nanoengineer

устранение неисправностей

в Debian Jessie вы получите сообщение об ошибке, о котором упоминалось в cant pants. Кажется, в сценариях automake есть проблема. x86_64-linux-gnu-gcc вставить в CFLAGS и gcc будет интерпретировать это как имя одного из исходных файлов. В качестве обходного пути, давайте создайте пустой файл с таким именем. Пусто, чтобы он не изменил программу и само это имя, чтобы компилятор взял его. Из клонированного каталога nanoengineer запустите эту команду, чтобы сделать gcc счастливым (это хак да, но он работает) .

если вы получаете сообщение об ошибке при попытке скомпилировать HDF5 по строкам: «ошибка: вызовите» __open_missing_mode», объявленный с атрибутом error: open with O_CREAT во втором аргументе требуется 3 аргумента», затем измените файл perform/zip_perf.c, строки 548 выглядеть следующий и повторно запустите сделает.

если появляется сообщение об ошибке Numeric / arrayobject.h не найден при создании Наноинженера, попробуйте запустить

если появляется сообщение об ошибке, подобное «TRACE_PREFIX undeclared», измените файл sim/src/simhelp.c строк 38 до 41, чтобы выглядеть так и повторно запустить make:

если при попытке запуска появляется сообщение об ошибке NanoEngineer-1, который упоминает что-то похожее на «не удается импортировать имя GL_ARRAY_BUFFER_ARB», измените строки в следующих файлах

это выглядит так:

я также нашел дополнительный текстовый файл для устранения неполадок, который был удален, но вы можете найти его здесь

Источник

LFS проблемы с gcc

Здравствуйте! Я новичок в linux. LFS — для того, что бы разобраться что к чему. Да и к тому же много много веселья)
Дошел до пункта 5.5.

>Вроде make выполнился без ошибок

А это что?
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/mnt/lfs/gcc-build/gcc-4.5.2′ make: *** [all] Error 2

Очевидно, вы пытаетесь собрать gcc в каталоге с его исходниками, несмотря на то, что в инструкции написано:

Это не поддерживается, те вам нужно создать отдельный каталог, и запускать configure && make уже оттуда.

внимательно читатайте манул

мне почти удалось всё собрать.

используйте только те версии пакетов которые там указаны

нет, это первый вывод. потом порылся, нашел то самое решение, снова запустил make и make install и не увидел ошибок, только насторожила скорость выполнения.

Очевидно, вы пытаетесь собрать gcc в каталоге с его исходниками

Исходники в sources, создал папку gcc-build, скопировал туда исходники gcc, распаковал и пытаюсь там собрать. Да, видимо сглупил. Получается, мне нужно в gcc-build создать папку и из нее запускать «/mnt/lfs/gcc-build/gcc-4.5.2/configure \»?

Спасибо большое!
По-моему, вы указали на основную мою ошибку.. А как тогда быть потом с обновлениями? Или сначала главное все собрать, а обновляться легче будет?

>>мне почти удалось всё собрать.

не знаю, до финиша у меня дойти не получилось

> А как тогда быть потом с обновлениями?
Фактически, никак. Никакой системы обновлений нет.
Поставь арч, советую тебе ещё раз.

>нет, это первый вывод. потом порылся, нашел то самое решение

Если следовать инструкции, проблемы не было бы.

Исходники в sources, создал папку gcc-build, скопировал туда исходники gcc, распаковал и пытаюсь там собрать.

Если скопировать каталог с сорцами пару раз он перестаёт таким быть? Лол, или что ты пытаешься сказать?

Если следовать инструкции, проблемы не было бы.

Если скопировать каталог с сорцами пару раз он перестаёт таким быть? Лол, или что ты пытаешься сказать?

Кретинизм мозга не позволяет дочитать до конца?

И еще, хватит насаждать всем свое мнение. Не знаешь как решить проблему, зачем тогда вообще что-то писать?

Ты чо такой дерзкий? 😀 Вопрос был в этом:

если я совершил тупейшие и очевидные ошибки, готов выслушать критик

В 4-ом посте я признал свою ошибку, а вы снова указываете мне на нее. Я понял с первого раза. Спасибо.

>Надеюсь, правильно понял смысл «j2» — аналог MAKEOPTS, который в /etc/make.

-j2 у make — это параллельная сборка в два потока. Это ускоряет сборку, но некоторые программы могут так не собраться, если авторы не протестировали параллельную сборку.

Можно при выходе новой версии просто собрать её и установить, она перезапишет старые файлы, обычно всё работает хорошо.

Источник

Debugging the error «gcc: error: x86_64-linux-gnu-gcc: No such file or directory»

But it looks like it errors out on:

x86_64-linux-gnu-gcc definitely exists in /usr/bin (It’s a symlink) and the target definitely exists as well. It looks to me like the Makefile wasn’t generated correctly, perhaps there is a flag that should be passed before specifying x86_64-linux-gnu-gcc? I am unsure as well what specifying x86_64-linux-gnu-gcc is supposed to accomplish.

Finally, this makefile was generated by configure, so once we narrow down the cause of the error, I’ll have to figure out what files to modify in order to fix this. (I’m a CMake kind of guy myself, but of course I didn’t choose the build system for this project.) My OS is Debian.

If you can try getting this to build on your system, I would greatly appreciate it! Thanks!

9 Answers 9

After a fair amount of work, I was able to get it to build on Ubuntu 12.04 x86 and Debian 7.4 x86_64. I wrote up a guide below. Can you please try following it to see if it resolves the issue?

If not please let me know where you get stuck.

Install Common Dependencies

Install NumArray 1.5.2

Install Numeric 23.8

Install HDF5 1.6.5

Install Nanoengineer

Troubleshooting

On Debian Jessie, you will receive the error message that cant pants mentioned. There seems to be an issue in the automake scripts. x86_64-linux-gnu-gcc is inserted in CFLAGS and gcc will interpret that as a name of one of the source files. As a workaround, let’s create an empty file with that name. Empty so that it won’t change the program and that very name so that compiler picks it up. From the cloned nanoengineer directory, run this command to make gcc happy (it is a hack yes, but it does work) .

If you receive an error message when attemping to compile HDF5 along the lines of: «error: call to ‘__open_missing_mode’ declared with attribute error: open with O_CREAT in second argument needs 3 arguments», then modify the file perform/zip_perf.c, line 548 to look like the following and then rerun make.

If you receive an error message about Numeric/arrayobject.h not being found when building Nanoengineer, try running

If you receive an error message similar to «TRACE_PREFIX undeclared», modify the file sim/src/simhelp.c lines 38 to 41 to look like this and re-run make:

If you receive an error message when trying to launch NanoEngineer-1 that mentions something similar to «cannot import name GL_ARRAY_BUFFER_ARB», modify the lines in the following files

that look like this:

to look like this:

I also found an additional troubleshooting text file that has been removed, but you can find it here

Источник

Unknown compiler: x86_64-linux-gnu-gcc #3

Comments

salvadormrf commented Oct 17, 2014

I was trying to run the basic sum example, but seems the compiler does not get detected.

The text was updated successfully, but these errors were encountered:

iankronquist commented Oct 17, 2014

I fired up an ubuntu VM and can confirm this is an issue.

fermat618 commented Oct 18, 2014

the same problem in Debian Jessie

iankronquist commented Oct 18, 2014

@fermat618 The issue is that hope doesn’t really support linux right now. When it queries a python library for your C compiler it gets a compiler it doesn’t know what to do with. I have a PR open to add CXXFLAGS for a generic x86_64 linux target. If you’d like to try it out, check out my fork:
https://github.com/iankronquist/hope/tree/linux-compiler-support-3

cosmo-ethz commented Oct 19, 2014

So far, we have been using the package mostly on OS X, ScientificLinux and Debian boxes where the current compiler detection seems to do its job. However, we have seen this error on Ubuntu VM’s before and it seemed that the compiler that is found heavily depends on how the system is set up. We definitely need to figure out how to deal with this situation.

However, this problem can be overcome by exporting the CC and CXX environment variables (e.g. export CC=

cosmo-ethz commented Oct 22, 2014

@salvadormrf , @iankronquist with my latest changes HOPE should support x86_64-linux-gnu-gcc .

I check the fix on a Ubuntu box. @fermat618 would be great if you could check this fix on your Debian machine as on mine the old compiler detection seemed to work.

fermat618 commented Oct 22, 2014

@cosmo-ethz this bug seems to be fixed, but I still cannot use hope.

cosmo-ethz commented Oct 22, 2014

@fermat618 thanks for checking!
Regarding the error: HOPE does not support lambda expressions.

If you do something like this instead it should work:

fermat618 commented Oct 23, 2014

cosmo-ethz commented Oct 24, 2014

We don’t set the ‘-fstack-protector-strong’ argument for the compilation. From what I have seen while debugging, distutils.sysconfig reads out the Makefile that was used to compile Python and enhances the argument list with environment variables ( OPT , CFLAGS ). Could it be that this arg is in your env?

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Compiling 32-bit GTK+ Applications of 64 bit Linux

I am having some trouble compiling 32-bit GTK+ applications on 64-bit Linux, specifically Ubuntu 10.04. Compiling 64-bit GTK+ applications works fine, and everything is set up to compile 32-bit apps as well, but it doesn’t work with GTK+

I have a very simple test program that I am using for trouble shooting that is simply a gtk_init and a gtk_main, which compiles fine as -m64. I am compiling with gcc 4.6.2, calling it with:

These are the two different kinds of error messages I get:

Keep in mind that these aren’t the only errors, I just included the two specific types for reference and to keep it short, I get errors for the whole stack of GTK+ libraries.

I do have all of the proper 32-bit versions of the libraries in my lib32 folders.

Hopefull someone has had this problem before and can help me, this is really causing me quite the headaches, and I can’t fine much help any where on the net.

Please ask if there is any other information you need me to provide to help with diagnosing this problem.

Note: I do have the ia32-libs and gcc-multilib packages. Ubuntu 10.04 does not have a separate ia32-libs-gtk packages, but I think these are wrapped in to the ia32-libs packages. They all are present on my system.

I think this must be some sort of linker config problem. I’ve recently built the new Free Pascal compiler and a 32 bit cross compiler, and I also upgraded GCC to 4.6.2 to take advantage of some of the new C++ features and fixes to C99 support. The default 4.4.3 GCC still exists on my system. Where I think the problem has been introduced is when I installed a new binutils because I’ve been experimenting with Clang and LLVM as a toolchain, and I wanted and ld with plug-in capabilities, so I figured might as well upgrade them all.

Everything works fine compiling 64 bit programs, there hasn’t been a single problem with the new tools at all, and I can compile 32-bit programs but when it comes time to explicitly link something in I have problems.

I know my current set of libs is appropriate, and I have Free Basic installed which only emits 32 bit code, and I was able to build 32-bit GTK+ programs no problem before this upgrade.

Just wondering if anyone has any ideas what configs might have been changed in this upgrade or has had this happen to them before? I really should upgrade to a newer distro so I can take advantage of all the new software with out have to hack up all of my packages, but unfortunatly there is a bug in the newer kernels that prevents my computer from coming back from standby, and this is a laptop I use for personal side projects, so proper power management is pretty important, and it’s not a huge loss if I bork the system, other than I have it set up pretty much perfect for my workflow.

Источник