Hello,

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? Thanks.

Regards, Bernd.

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

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.

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

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.

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.

Why do you limit it to Linux targets?

Jonas

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.

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

One could work with a default suffix ".so" and make this overridable by a new test option for example TEST_LIBRARY_SUFFIX.

Regards, Bernd.

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

Just add a LibExt constant to dotest.pp source
with the same conditionals as for ExeExt, this should be enough.

Pierre Muller

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.

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.

Yes, your right...

Jonas