Вопросы Теги

компиляция с gcc, поврежденным для пользователей, но прекрасным для корня

Вы могли использовать su[YourUserName]-c /usr/bin/vncserver выполнять vncserver как пользователя, не как корень.

Другая точка: В Вашем сценарии нет никакого различия между запуском и остановкой сервера VNC. Обычно, init сценарий использовал бы различные случаи для запущения/останавливания сервиса:

case "$1" in
    start)
    # code to start the application
    ;;

    stop)
    # code to stop the application
    ;;

    restart)
    $0 stop
    $0 start
    ;;
esac

Вот разработанный пример, как запустить vnc сервер с помощью init сценария.

1
08.12.2012, 14:46
2 ответа

Я не думаю, что существует особенно хороший способ полностью проигнорировать его (это возможно с gcc nostdinc переключатель, но затем необходимо будет добавить-I для всех необходимых путей).

Однако существует простой способ вынудить компилятор выбрать тот, который Вы хотите. Согласно http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html, нормальный порядок включает пути:

 /usr/local/include
 libdir/gcc/target/version/include
 /usr/target/include
 /usr/include

По-видимому, это должно позволить, Вы для легкого переопределения системы включаете с локальным пользователем один. Но что превосходит все, что это-I, поэтому если Вы компилируете:

gcc -I/usr/include/sys

Затем это выберет cdefs.h оттуда. Это не устранит/usr/local/include из пути tho, поэтому если будут другие файлы, которые попадают в эту категорию, Вам, возможно, понадобится больше-I's. Они не являются рекурсивными, так например:

gcc -I/usr/include

Не расположит по приоритетам/usr/include/sys, так же, как другая версия не расположит по приоритетам/usr/include. Таким образом, Вам, возможно, понадобилось бы:

gcc -I/usr/include -I/usr/include/sys

Используя make-файл делает эти виды вещей значительно легче, btw. В конечном счете Вы захотите изучить, как сделать это.

Могут быть некоторые другие проблемы, с которыми Вы столкнетесь связанный с тем, что причина того, чтобы копировать этот заголовок, но необходимо будет объяснить это. Эта Ваша система?

1
27.01.2020, 23:54

Я попытался фиксировать перманент, но я не могу разобраться в нем. Существует ли способ проигнорировать cdefs.h от/usr/local и использовать тот это/usr/include/?

Да, не устанавливайте их в /usr/local/. Debian ничего никогда не будет устанавливать в /usr/local, таким образом, если существуют файлы здесь, это - потому что Вы, другие локальные администраторы или плохо серийное программное обеспечение установили эти вещи здесь. Установите их где-либо еще. Но установка заголовков другого libc в/usr/local напрашивается на неприятности.

0
27.01.2020, 23:54
  • 1
    Нет ничего неправильно со вставлением материала /usr/local. Причина Debian (или любой другой дистрибутив) не устанавливает материал, состоит в том, потому что это не то, для чего это - это для стороннего программного обеспечения. Это - лучшая практика для использования /usr/local для стороннего материала, чем использовать /usr постараться не перезаписывать материал пакета дистрибутива. Конечно, это может привести к дублированиям, но это лучше, чем то, что заменило системный файл одним от третьей стороны. –  goldilocks 08.12.2012, 16:39
  • 2
    @goldilocks: проблема с наличием другого программного обеспечения /usr и /usr/local не о дублировании, это о конфликтах. Установка libc в /usr/local ЯВЛЯЕТСЯ Неправильным. Помещенный, что (и все третье лицо) в /opt. –  BatchyX 08.12.2012, 16:51
  • 3
    я соглашусь, что установка libc в/usr/local не должна быть сделана волей-неволей. При установке libc в каком-либо стандартном пути - Вы действительно понимаете, что/usr/local находится в этом? Таким образом, что это для? ;) - сверху дистрибутива не нужно сделаться волей-неволей. Однако сказать, что "неправильно установить программное обеспечение в/usr/local", является, ну, в общем, просто неправильным. –  goldilocks 08.12.2012, 16:56
  • 4
    @goldilocks: Путем установки программного обеспечения на /usr/local, необходимо пребывать к тому, что программное обеспечение должно быть совместимо с существующим программным обеспечением в системе/распределении и любым более поздним обновлением, которое можно установить. Если Вы не можете гарантировать, что (и большую часть времени, не делаете, или Вы не заботитесь), то установка в /usr/local является неправильным. /usr/local может быть стандартным, но так /opt. Установка любого программного обеспечения (включая libcs) в /opt может быть сделан волей-неволей и может управляться более легко. –  BatchyX 08.12.2012, 20:21
  • 5
    @goldilocks, @BatchyX: хорошо, установка чего-либо, что Вы не гарантируете, будет работать с обновлениями, где угодно просит проблемы.Разница между /usr и /usr/local является историческим: /usr часто используемый, чтобы быть сетью смонтировал файловую систему (обычно только для чтения), и /usr/local место состояло в том, чтобы поместить файлы в масштабе всей системы, которые присутствовали на локальном устройстве хранения данных. /opt был предназначен для коротковолнового от других поставщиков. Следовательно одни из основных отличий между /usr/local и /opt что первое обычно находится в $PATH и /opt должен иметь поддеревья на приложение (сегодня, например. /opt/kde3). –  peterph 09.12.2012, 01:00

Теги

Похожие вопросы