Почему здание является кросс-компилятором тяжелее, чем создание обычного компилятора?
Может быть, это могло бы помочь. когда я сохраняю токен доступа в моем приложении внешнего интерфейса, я также присоединяю заголовок
axios.defaults.headers.common['Authorization'] = "Bearer " + token.data.access_token
ко всем вашим запросам axios будет использоваться этот заголовок.
получение сведений о пользователе
Route::middleware('auth:api')->get('/user', function (Request $request) {
return $request->user();
});
7 ответов
"создание кросс-компилятора значительно более трудно, чем создание компилятора, который предназначается для платформы, на которой это работает".
Проблема существует из-за способа, которым библиотеки созданы и получены доступ.
В нормальной ситуации все библиотеки расположены в определенном месте и пользуются всеми приложениями в той системе. Все механизмы сборки и программное обеспечение принимают местоположение библиотек. make-файлы, компиляторы, и т.д. зависят от идеи, что они могут перейти к определенному месту и найти то, в чем они нуждаются.
В перекрестном случае компиляции, тем не менее, кросс-компилятор, make-файлы, и т.д. не может сделать эти предположения - если они сделают то они свяжут неправильные библиотеки.
Таким образом, это действительно сводится к тому, что разработчики сделали определенные предположения вначале, и мы застреваем с этим.
Становится более трудным при создании корневых файловых систем так как Unix только знает об одной корневой файловой системе. При создании другой корневой файловой системы, необходимо создать специальную среду, которая позволяет Вам управлять ею, не влияя на реальную корневую файловую систему.
- Adam
Создание кросс-компилятора трудно, только если Вам никогда не приходит в голову, что Вы могли бы хотеть кросс-скомпилировать. То же верно, интересно достаточно, ассемблеров, компоновщиков и отладчиков. Все, что необходимо сделать, не забывают создавать явную абстракцию для представления то, что Вы знаете о целевой машине.
Для примера очень хорошо разработанного, хорошо зарегистрированного кросс-компилятора проверьте lcc. Для чтения о дизайне перекрестного отладчика существуют труды конференции и докторская диссертация. Код может быть загружаем; я не уверен.
Это не должно быть более твердо, но это может быть в зависимости от архитектуры компилятора.
Компилятор не только переводит исходный код в asm и системные вызовы. Это также интегрирует существующий ранее код помощника в сгенерированные файлы. Это - код, включает код запуска, преамбулу функций, часть API C, который может быть встроен и т.д.
В нормальном компиляторе C1 для платформы основанный платформа A, исходном компиляторе C0 может создать C1 и его код помощника (для A, так как C0 предназначается для A), непосредственно.
В кросс-компиляторе C2 для платформы B основывался на платформе A, исходный компилятор, C0 должен сначала создать специальную версию C2, которому не нужен код помощника (потому что код помощника для B, в то время как C0 предназначается для A), затем это должно выполнить C2, чтобы сгенерировать код помощника. В зависимости от компилятора этому, вероятно, затем придется генерировать вторую версию C2, который включает код помощника.
Действие создания ограниченной версии C2, без кода помощника является начальной загрузкой.
Действительно ли возможно, что Вы смотрите на конкретный случай как 'создание GCC как кросс-компилятор', где 'здание' означает 'компилировать' вместо 'записи'?
Это могло бы быть более твердо из-за проблем окружающие библиотеки - для кросс-компилятора, Вам нужны библиотеки для целевой платформы. Для 'собственного компонента' (т.е. некрест) компилятор, у Вас ясно уже есть целевые библиотеки.
Я - с Вами на 'создании генератора кода' аспекты, являющиеся тем же - или по крайней мере более затрагиваемые архитектурой целевого процессора, чем тем, где компилятор выполняется.
И существуют ясные ситуации, где кросс-компилятор намного легче, чем неперекрестный. Я думаю, что 8051 размещенный компилятор C++ был бы тяжелой работой, безотносительно платформы, для которой это предназначалось.
Много кросс-компиляторов имеют несколько целей. Я думаю в целом, что мультицелевой компилятор намного более тверд, чем компилятор единой цели, и все мультицелевые компиляторы являются по определению кросс-компиляторами. Поэтому много кросс-компиляторов намного более сложны, чем не кросс-компиляторы.
При записи компилятора на платформе, который компилирует код только для платформы, B не должен в принципе быть немного тяжелее, чем запись компилятора на платформе, который компилирует только для платформы A.
Это отвечает за следующий вопрос, может выручить Вас в понимании, почему это было бы твердо.
Почему мы не можем создать перекрестные платформы программ в эти дни?
Я чувствую, что все это сводится к различным операционным системам, называя собственный IO по-разному. Для создания компилятора платформы-independant, Вы оказываетесь перед необходимостью знать точно, как все вшивые песчаные работы и в основном создают ОС.
[Я обновлю, когда я возвращусь домой, поскольку я должен отбыть из работы теперь]
Вот некоторые из проблем, с которыми я столкнулся при кросс-компиляции GCC:
У вас должны быть некоторые системные файлы из целевой системы, присутствующие в хост-системе ( т. е. системный корень) для связывания с.
Некоторые языки требуют, чтобы вещи оценивались во время компиляции, а не во время выполнения; кроме того, некоторые оптимизации приводят к оценке вещей во время компиляции, которые (в неоптимизированном случае) оцениваются во время выполнения. Когда цель имеет числовые типы, которых нет в хост-системе, бывает сложно получить один и тот же ответ во время компиляции и во время выполнения.
Тестирование может быть немного более раздражающим. У вас должны быть две системы и способ передачи программы от одной к другой.
На самом деле, это все, что касается общих проблем, с которыми я столкнулся.