Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote:
Isn't it easier to simply copy all compiled libraries to the target when
they are compiled (just like compiled test programs are copied)?
this second approach (which works well for me) copies the libraries when
the are compiled. No need to expand the %needlibrary directive.
Regards, Bernd.
Index: tests/utils/dotest.pp
===
--- tests/utils/dotest.pp (Revision 17610)
+++ tests/utils/dotest.pp (Arbeitskopie)
@@ -930,6 +930,8 @@
str(Config.Timeout,s);
execcmd:=execcmd+s;
end;
+ if Config.NeedLibrary then
+ execcmd:=execcmd+'export LD_LIBRARY_PATH='+RemotePath + ' ; ';
{ as we moved to RemotePath, if path is not absolute
we need to use ./execfilename only }
if not isabsolute(TestRemoteExe) then
@@ -1185,6 +1187,8 @@
var
PPDir : string;
Res : boolean;
+ LocalLibraryFile, LibraryFileName: String;
+ execres: Boolean;
begin
Res:=GetConfig(PPFile[current],Config);
@@ -1398,6 +1402,20 @@
begin
if (Config.NoRun) then
begin
+if (CompilerTarget = 'linux') and (RemoteAddr '') then
+{ if test program is a library, copy the library to the target }
+begin
+ LibraryFileName:= 'lib' +
ForceExtension(SplitFileName(PPFile[current]), 'so');
+ LocalLibraryFile:= OutputDir + '/' + SplitPath(PPFile[current]) +
LibraryFileName;
+ if FileExists(LocalLibraryFile) then
+ begin
+ execres:=ExecuteRedir(rcpprog,RemotePara+' '+ LocalLibraryFile+'
'+RemoteAddr+':' + RemotePath+'/'+ LibraryFileName,'',EXELogFile,'stdout');
+ if not execres then
+ begin
+Verbose(V_normal, 'Could not copy library ' + LibraryFileName);
+ end;
+ end;
+end;
{ avoid a second attempt by writing to elg file }
AddLog(EXELogFile,skipping_run_test+PPFileInfo[current]);
AddLog(ResLogFile,skipping_run_test+PPFileInfo[current]);
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:04, Bernd Mueller wrote: Jonas Maebe wrote: Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? this second approach (which works well for me) copies the libraries when the are compiled. No need to expand the %needlibrary directive. Why do you limit it to Linux targets? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 30 May 2011, at 11:04, Bernd Mueller wrote: Jonas Maebe wrote: Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? this second approach (which works well for me) copies the libraries when the are compiled. No need to expand the %needlibrary directive. Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 11:37, Bernd Mueller wrote: Jonas Maebe wrote: Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. Most other targets use libc by default anyway (and if new non-libc targets are added or brought back to life, the ifdef can be adjusted in case the libc dependency would cause problems). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] test suite, problem with missing libraries on the target
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Bernd Mueller Envoyé : lundi 30 mai 2011 11:38 À : FPC developers' list Objet : Re: [fpc-devel] test suite, problem with missing libraries on the target Jonas Maebe wrote: On 30 May 2011, at 11:19, Bernd Mueller wrote: Jonas Maebe wrote: Why do you limit it to Linux targets? I am not sure about the other targets. LibraryFileName:= 'lib' + ForceExtension(SplitFileName(PPFile[current]), 'so'); The above code builds the library name out of the test program name. For example Test1.pp becomes libTest1.so. This cannot be right for a Windows target for example. Windows is not supported as a remote target, but it's indeed not correct for all unix targets either. The prefix of a library is always lib on all targets, afaik. The suffix is available via dynlibs.SharedSuffix. The downside of using the dynlibs unit is that it makes the dotest program dependent on libdl (and hence libc) on Linux-targets. I'm not sure about how to best solve this... One could work with a default suffix .so and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX. Just add a LibExt constant to dotest.pp source with the same conditionals as for ExeExt, this should be enough. Pierre Muller ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Pierre Free Pascal wrote:
Just add a LibExt constant to dotest.pp source
with the same conditionals as for ExeExt, this should be enough.
const
ObjExt='o';
PPUExt='ppu';
{$ifdef UNIX}
ExeExt='';
LibExt='so';
{$else UNIX}
{$ifdef MACOS}
ExeExt='';
LibExt='so';
{$else MACOS}
ExeExt='exe';
LibExt='dll'; ???
{$endif MACOS}
{$endif UNIX}
but wouldn't that fail with crosscompiling? I am crosscompiling from a
Windows host.
Regards, Bernd.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve the library suffix for the host? So, when I am crosscompiling from Windows, I would get the wrong suffix for the Linux target? Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 30 May 2011, at 13:53, Bernd Mueller wrote: Jonas Maebe wrote: Maybe better would be to hardcode .so for Linux and FreeBSD, and use dynlibs.SharedSuffix for all other targets. maybe I am missing something, but wouldn't dynlibs.SharedSuffix retrieve the library suffix for the host? Yes, your right... Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote:
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically copied
to the target. For example:
Failed to run test/tlib1b.pp 2011/01/21 18:06:08 (16)
/mnt/tlib1b: can't load library 'libtlib1a.so'
My target has very low resources so that I can not run the test suite
directly on the target. How can my problem be solved?
Maybe you are using TEST_DELTEMP=1? If so, remove it if you have enough
disk space on the remote target. Most test sources that are later on
used by other tests don't contain the necessary { %neededafter }
directive, so they are immediately deleted even when they are still
required later
Alternatively, you can submit a patch that adds { %neededafter } to all
affected tests).
I have enough FLASH memory, so I am not using TEST_DELTEMP=1. I had a
look into the test suite source and I think, that the test suite is not
able to copy the libraries to the target.
I attached a small patch, which could be a solution for the problem. I
am using the parameter of the %needlibrary directive to get the
information, which library should be copied. For example in tlib1b.pp,
the directive is expanded to { %needlibrary=tlib1a }. This works for me.
If you think, this patch could be the right way to copy the libraries, I
would submit a second patch which expands all required %needlibrary
directives.
Regards, Bernd.
Index: tests/utils/dotest.pp
===
--- tests/utils/dotest.pp (Revision 17059)
+++ tests/utils/dotest.pp (Arbeitskopie)
@@ -811,6 +811,7 @@
index: integer;
EndTicks,
StartTicks : int64;
+ LibraryFileName, LocalLibraryFile: string;
function ExecuteRemote(const prog,args:string):boolean;
var
Trials : longint;
@@ -913,6 +914,21 @@
s:=copy(s,index+1,length(s)-index);
until false;
end;
+
+ { copy library to target }
+ if (CompilerTarget = 'linux') and (Config.LibraryName '') then
+ begin
+ LibraryFileName:= 'lib' + Config.LibraryName + '.so';
+ LocalPath:=SplitPath(PPFile[current]);
+ LocalLibraryFile:= OutputDir + '/' + LocalPath + LibraryFileName;
+ execres:=ExecuteRemote(rcpprog,RemotePara+' '+ LocalLibraryFile+'
'+RemoteAddr+':' + RemotePath+'/'+ LibraryFileName);
+ if not execres then
+ begin
+ Verbose(V_normal, 'Could not copy library ' + LibraryFileName);
+ goto done;
+ end;
+ end;
+
{ rsh doesn't pass the exitcode, use a second command to print the
exitcode
on the remoteshell to stdout }
if DoVerbose and (rshprog='plink') then
@@ -936,6 +952,8 @@
execcmd:=execcmd+' ./'+SplitFileName(TestRemoteExe)
else
execcmd:=execcmd+' '+TestRemoteExe;
+ if Config.LibraryName '' then
+execcmd:=execcmd+' ; export LD_LIBRARY_PATH='+RemotePath;
execcmd:=execcmd+' ; echo TestExitCode: $?';
if (deAfter in DelExecutable) and
not Config.NeededAfter then
Index: tests/utils/testu.pp
===
--- tests/utils/testu.pp(Revision 17059)
+++ tests/utils/testu.pp(Arbeitskopie)
@@ -28,6 +28,7 @@
KnownCompileError : longint;
NeedRecompile : boolean;
NeedLibrary : boolean;
+LibraryName : string;
NeededAfter : boolean;
IsInteractive : boolean;
IsKnownRunError,
@@ -212,7 +213,10 @@
r.NoRun:=true
else
if GetEntry('NEEDLIBRARY') then
-r.NeedLibrary:=true
+begin
+ r.NeedLibrary:=true;
+ r.LibraryName:= res;
+end
else
if GetEntry('NEEDEDAFTER') then
r.NeededAfter:=true
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 27 May 2011, at 14:56, Bernd Mueller wrote:
I have enough FLASH memory, so I am not using TEST_DELTEMP=1. I had
a look into the test suite source and I think, that the test suite
is not able to copy the libraries to the target.
I attached a small patch, which could be a solution for the problem.
I am using the parameter of the %needlibrary directive to get the
information, which library should be copied. For example in
tlib1b.pp, the directive is expanded to { %needlibrary=tlib1a }.
This works for me.
If you think, this patch could be the right way to copy the
libraries, I would submit a second patch which expands all required
%needlibrary directives.
Isn't it easier to simply copy all compiled libraries to the target
when they are compiled (just like compiled test programs are copied)?
I thought that was already being done, but if I understand you
correctly that's not the case.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
Jonas Maebe wrote: On 27 May 2011, at 14:56, Bernd Mueller wrote: If you think, this patch could be the right way to copy the libraries, I would submit a second patch which expands all required %needlibrary directives. Isn't it easier to simply copy all compiled libraries to the target when they are compiled (just like compiled test programs are copied)? I thought that was already being done, but if I understand you correctly that's not the case. you are right, it would probably be better to copy the libraries to the target when the are compiled. I have to look into the code, how that can be done. All I can say for now (without the patch) the libraries were produced by the compiler, but remain on the host. Regards, Bernd. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] test suite, problem with missing libraries on the target
On 23 May 2011, at 11:49, Bernd Mueller wrote:
I am running the test suite with remote execution (from a Windows
host) on an ARM-Linux target. Some test programs fail at runtime,
because they depend on libraries, which were not automatically
copied to the target. For example:
Failed to run test/tlib1b.pp 2011/01/21 18:06:08 (16)
/mnt/tlib1b: can't load library 'libtlib1a.so'
My target has very low resources so that I can not run the test
suite directly on the target. How can my problem be solved?
Maybe you are using TEST_DELTEMP=1? If so, remove it if you have
enough disk space on the remote target. Most test sources that are
later on used by other tests don't contain the necessary
{ %neededafter } directive, so they are immediately deleted even when
they are still required later
Alternatively, you can submit a patch that adds { %neededafter } to
all affected tests).
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
