Непонятки с dll в Линуксе

[Cheb]

1. При кросс-компиляции с -Twin32 создаёт совершенно нормальную, идеально работающую dll, спокойно пакующуюся upx'ом.
Но сопровождается это воплем:

Linking ../_demo001.dll
/usr/bin/fpc-i386-win32-dlltool: Path components stripped from dllname, '../_demo001.dll'.
/usr/bin/fpc-i386-win32-dlltool: Unable to open object file:
_demo001.dpr(79,1) Error: Error while linking
Error: /usr/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)

и Лазарь швыряет меня из моей позиции в окне редактора к последней строчке главного *.dpr файла -- что ужасно раздражает, поскольку случается при каждой компиляции.

Есть идеи, какого беса этому fpc-i386-win32-dlltool надо?

мой build.sh:

Код: Выделить всё

rm ../../../temp/*
rm ../lib_demo001.so
fpc _demo001.dpr -dcge -dnotlaz -O2 -Op3 -Or -Sd -Sh -Sc -Rintel -Fi../../cge/src -FE../ -FU../../../temp
strip -s ../lib_demo001.so
upx ../lib_demo001.so

Соответственно, готовый продукт кладётся в папку одним уровнем выше, чем исходники. build.sh вызывается Лазарем вместо штатного вызова компилятора.

2. При компиляции под Линь lib*.so получаются в *три* раза больше объёмом (два метра, strip обрезает лишь до полутора) чем собранные из тех же сорцов *.dll. Причём, upx их не жмёт:

upx: ../lib_demo001.so: UnknownExecutableFormatException

Код - чистый fpc, из модулей подключаю самый минимум: classes, x, xlib, xutil, dl. Откуда этот лишний мегабайт выползает? Прилинковывает оно что-нибудь, что-ли?

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

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

[Cheb]

Океюшки... Раз никто не смог помочь, взялся за дело сам. По крайней мере. удалось избавиться от ложных "Error while linking", страшно меня достававших.

Пишется ма-ахонький враппер, которым подменяется /usr/bin/fpc-i386-win32-dlltool, а оригинальная переименовывается в *-orig

Код: Выделить всё

program fpc_i386_win32_dlltool;
{$mode objfpc}{$H+}
uses
  Classes, SysUtils, Process;
  var
    i: integer;
    s: ansistring;
    AProcess: TProcess;
begin
  s:=ParamStr(1);
  For i:=2 to ParamCount() do
    s:=s + ' ' + ParamStr(i);
  WriteLn('wrapping: fpc-i386-win32-dlltool ', s);
  AProcess:=TProcess.Create(nil);
  AProcess.CommandLine := 'fpc-i386-win32-dlltool-orig '+ s;
  AProcess.Options := AProcess.Options + [poWaitOnExit];
  AProcess.Execute;
  AProcess.Free;
end.

- и ошибка перестаёт лезть.
Причём. заметьте, если вместо TProcess применять Shell() или ExecuteProcess() то ошибки всё равно лезут, причём совершенно дикие - от жалоб на несуществующие файлы до исключений во враппере (причём, если исключения эти не ловить, то ругается но создаёт нормальную dll, а если ловить, то валится уже fpc-i386-win32-ld, которому эта самая dlltool, судя по всему, должна была скормить какой-то файл, и dll не создаётся).

Короче, какой-то эзотерический баг.
Шаманы среди присутствующих есть?

[shade]

А проще проблему не пробовал решить:
собирать библиотеку на месте, а затем уже копировать/перемещать (по-вкусу) на нужное место, ну чтобы просто вместо '../_demo001.dll' было '_demo001.dll' :?::?:

[Cheb]

Что самое смешное - я сейчас так и делаю:

rm ../_demo001.dll
rm _demo001.dll
fpc _demo001.dpr -Twin32 -dcge -dnotlaz -O2 -Op3 -Or -Sd -Sh -Sc -Rintel -Fi../../cge/src -FU../../../temp -Fu../../../temp
../../../bin/incbuild build.h
strip -s _demo001.dll
upx _demo001.dll
mv _demo001.dll ../
rm ../../../temp/*

Всё, что это дало - изменился тип нытья. Стало:

/usr/bin/fpc-i386-win32-dlltool: Unable to open object file:
/usr/bin/fpc-i386-win32-dlltool: Unable to open object file:
/home/cheb/cge/modules/_demo001/src/_demo001.dpr(79,1) Error: Error while linking

И лишь добавление враппера полностью удалило этот неопасный но раздражающий баг.