Linking Free Pascal programs to include dependencies - static-linking

I have two Free Pascal units that I would like to use from a C program on linux.
Here is what I do:
$ fpc -fPIC base64.pas queueutils.pas
Warning: Only one source file supported
Free Pascal Compiler version 2.2.2 [2008/11/05] for x86_64
Copyright (c) 1993-2008 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling queueutils.pas
queueutils.pas(2088,11) Warning: Symbol "Socket" is deprecated
queueutils.pas(2097,10) Warning: Symbol "Connect" is deprecated
queueutils.pas(2104,3) Warning: Symbol "Sock2Text" is deprecated
2432 lines compiled, 0.5 sec
4 warning(s) issued
$ ppumove -o queueutils -e ppl *.ppu
PPU-Mover Version 2.1.1
Copyright (c) 1998-2007 by the Free Pascal Development Team
Processing base64.ppu... Done.
Processing queueutils.ppu... Done.
Linking queueutils.o base64.o
Done.
Seems fine so far, libqueueutils.so is created:
$ file libqueueutils.so
libqueueutils.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped
$ ldd libqueueutils.so
ldd: warning: you do not have execution permission for `./libqueueutils.so'
statically linked
However when the C program tries to use the library this way:
libqueue = dlopen("./libqueueutils.so", RTLD_LAZY);
if (!libqueue) {
fprintf (stderr, "%s\n", dlerror());
}
it yields an error message:
$ ./tmbrkr
./libqueueutils.so: undefined symbol: VMT_PROCESS_TPROCESS
This VMT_PROCESS_TPROCESS-related error is resolved if I add process.o and process.ppu to the linking process done by ppumove. However after doing so another unit is missing and after that another... You get it.
Is there a way to somehow link all the necessary units together in one .so file so that the C program can dlopen() the library properly?

Just like a normal binary (exe) is from a "program" source file , a .so/dll is created from a ''library'' sourcefile.
For the rest is the model is the same. You simply build the library mainprogram, and the compiler collects all units necessary and stuffs them in the .so.
With the exports keyword you can define what symbols to export.
library testdll;
uses x,y,z;
// define exportable symbols here
// some examples of symbol exports
exports
P1 index 1, // dll based on index
P2 name 'Proc2', // normal export with alternate external symbol
P3, // just straight export.
P4 resident // for some MCU use
;
begin
// startup code
end.
Also look up $soname $libsuffix and $libprefix in the manual.
Though I would recommend just using most recent 2.6.0, not some 5 year old 2.2.2
It might require recompiling FPC first with PIC though.

Related

wxwidget build failed - windows - mingw - mingw32-make: *** [..\..\lib\gcc_dll\wxmsw313u_gcc_custom.dll] Error 1

I was trying use build wxWidgets-3.1.3 with MinGW-W64 on a x64 windows machine.
I followed this thread, which lead me to download and building. So I installed it and some youtube videos said I need to build it now. So navigate to the installed folder and gave this command :
mingw32-make -f makefile.gcc BUILD=release SHARED=1 MONOLITHIC=1 UNICODE=1.
It took almost half an hour and now it's giving me error saying :
collect2.exe: error: ld returned 1 exit status
makefile.gcc:5329: recipe for target '..\..\lib\gcc_dll\wxmsw313u_gcc_custom.dll' failed
mingw32-make: *** [..\..\lib\gcc_dll\wxmsw313u_gcc_custom.dll] Error 1
Here is the full log file :
https://pastebin.com/zxeHhF6K
MinGW configuration :
Version : 8.1.0
Architecture : x86_64
Threads : posix
Exceptions : seh
Build version : 0
How can I solve this? I'm using CLion, is there any other short or easy way?
The relevant error is
..\..\lib\gcc_dll/libwxexpat.a(wxexpat_xmlparse.o):xmlparse.c:(.text+0x337d): undefined reference to `_imp__rand_s'
and it's very strange because MinGW-w64 8.1 is definitely supposed to have rand_s(). Are you sure you're using the right compiler? I.e. what does g++ -v give you if you run it from the same command prompt?
My only hypothesis is that it's some different (and much older) compiler and the solution would be to just use the right one instead.
Also, the next time you could use -j4 option with make if you have at least 4 logical CPUs in your machine (and chances are you do nowadays), to significantly speed up the build.
Looking back in my notes I once had an issue with missing rand_s() when building glib2 on a certain MinGW build.
I was able to fix it then by adding this at the top of the C file that called this function:
#include <time.h>
#include <stdlib.h>
int rand_s (unsigned int* r)
{
static int srand_called = 0;
if (!srand_called) {
srand(time(0));
srand_called++;
}
if (r)
*r = rand();
return 0;
}
In your case that would be in xmlparse.c.

How to build AWS C++ SDK on Solaris?

I am trying to build the AWS C++ SDK on Solaris, but I cannot do so successfully.
I found this open issue on the AWS C++ SDK page that says it is possible, but there is no guide on it and I am hoping somebody here can help.
Here is the command I use to build it:
$ cmake ../aws-sdk-cpp/ -DCMAKE_BUILD_TYPE=Debug -DBUILD_ONLY="s3"
Here is the output:
-- TARGET_ARCH not specified; inferring host OS to be platform compilation target
-- Building AWS libraries as shared objects
-- Generating linux build config
-- Building project version: 1.7.134
-- Configuring done
-- Generating done
-- Build files have been written to: /workspace/dmoini/sdk_build/.deps
gmake: Warning: File 'Makefile' has modification time 267 s in the future
gmake[1]: Warning: File 'CMakeFiles/Makefile2' has modification time 267 s in the future
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
gmake[2]: warning: Clock skew detected. Your build may be incomplete.
gmake[2]: Warning: File 'CMakeFiles/AwsCCommon.dir/progress.make' has modification time 267 s in the future
[ 4%] Performing build step for 'AwsCCommon'
[ 1%] Building C object CMakeFiles/aws-c-common.dir/source/array_list.c.o
In file included from /usr/include/stdio.h:37:0,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/common.h:22,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/include/aws/common/array_list.h:18,
from /workspace/dmoini/sdk_build/.deps/build/src/AwsCCommon/source/array_list.c:16:
/opt/gcc-5.1.0/lib/gcc/i386-pc-solaris2.11/5.1.0/include-fixed/sys/feature_tests.h:405:2: error: #error "Compiler or options invalid for pre-UNIX 03 X/Open applications and pre-2001 POSIX applications"
#error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
^
gmake[5]: *** [CMakeFiles/aws-c-common.dir/build.make:63: CMakeFiles/aws-c-common.dir/source/array_list.c.o] Error 1
gmake[4]: *** [CMakeFiles/Makefile2:484: CMakeFiles/aws-c-common.dir/all] Error 2
gmake[3]: *** [Makefile:139: all] Error 2
gmake[2]: *** [CMakeFiles/AwsCCommon.dir/build.make:112: build/src/AwsCCommon-stamp/AwsCCommon-build] Error 2
gmake[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/AwsCCommon.dir/all] Error 2
gmake: *** [Makefile:84: all] Error 2
CMake Error at CMakeLists.txt:193 (message):
Failed to build third-party libraries.
Additionally, here is my system information:
$ uname -a
SunOS bld-dmoini-01-sv4b 5.11 omnios-r151020-4151d05 i86pc i386 i86pc
Any and all help/guidance is greatly appreciated.
I've successfully completed compiling the AWS C++ SDK on a stock install of Solaris 11.4, and found several issues that could cause the problems noted.
Start with a clean source tree.
Remove -Werror
The first thing do to is remove the -Werror compiler options. The version of OpenSSL installed by default on Solaris 11.4 has quite a few deprecated functions, and the -Werror option causes the build to fail when it runs into those deprecations. I used this find command run from the topmost directory of the AWS SDK source tree to remove all the -Werror options:
vi `find . | xargs grep -l Werror`
You'll get about three or four files, only two of which are actually setting the -Werror as a compiler option. Just remove the "-Werror" strings from those files.
Fix the POSIX defines
Then run cmake . in the topmost directory. It will fail because the cmake files that it downloads will have improper POSIX command-line options - -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=500. That 500 is wrong. _POSIX_C_SOURCE=200809L corresponds to _XOPEN_SOURCE=700. _XOPEN_SOURCE=500 is SUSv2, circa 1997. It's not proper to compile a SUSv2 application with C99.
Per 2.2.1 Strictly Conforming POSIX Application, paragraph 8:
For the C programming language, shall define _POSIX_C_SOURCE to be 200809L before any header is included
and 2.2.4 Strictly Conforming XSI Application, paragraph 8:
For the C programming language, shall define _XOPEN_SOURCE to be 700 before any header is included
Per the Illumos sys/feature_tests.h file (based on OpenSolaris, which was also the basis for Solaris 11):
* Feature Test Macro Specification
* ------------------------------------------------ -------------
* _XOPEN_SOURCE XPG3
* _XOPEN_SOURCE && _XOPEN_VERSION = 4 XPG4
* _XOPEN_SOURCE && _XOPEN_SOURCE_EXTENDED = 1 XPG4v2
* _XOPEN_SOURCE = 500 XPG5
* _XOPEN_SOURCE = 600 (or POSIX_C_SOURCE=200112L) XPG6
* _XOPEN_SOURCE = 700 (or POSIX_C_SOURCE=200809L) XPG7
The files cmake downloads via git need to be edited:
vi `find .deps | xargs grep -l XOPEN_SOURCE`
Change any -D_XOPEN_SOURCE=500 to -D_XOPEN_SOURCE=700 and rerun cmake .. It should complete successfully this time.
Then run gmake. (I find gmake works much better on Solaris for just about all open source projects, as many open source projects use GNU-specific make extensions.)
Now you get to fix any broken source code you run into.
Fix broken source code
1
The file aws-sdk-cpp/aws-cpp-sdk-core/source/platform/linux-shared/OSVersionInfo.cpp has the following wrong code:
Aws::String ComputeOSVersionString()
{
utsname name;
int32_t success = uname(&name);
Per POSIX, the correct type is struct utsname, not just utsname:
int uname(struct utsname *name);
The AWS code needs to be:
Aws::String ComputeOSVersionString()
{
struct utsname name;
int success = uname(&name);
And no, I'm most certainly not impressed with the quality of the AWS code, given this, umm, laugher:
while (!feof(outputStream))
Yes, an actual while (!feof()) loop...
2
The file aws-sdk-cpp/aws-cpp-sdk-mediaconvert/include/aws/mediaconvert/model/M2tsSegmentationMarkers.h uses an enumeration with the value EBP, which conflicts with the EBP register #define in /usr/include/sys/regset.h.
I just changed it to EBP_HASH as that seems to match the code somewhat:
vi `find . | xargs grep -l EBP`
3
The file aws-sdk-cpp/aws-cpp-sdk-route53domains/include/aws/route53domains/model/CountryCode.h creates an enumeration value ES that conflicts with the ES register #define in /usr/include/sys/regset.h. I just added
#ifdef ES
#undef ES
#endif
and the compile continued. I don't know if that #undef could have broken anything.
4
The file aws-sdk-cpp/aws-cpp-sdk-waf/include/aws/waf/model/GeoMatchConstraintValue.h has ES, GS, and SS enumeration value that conflict with the ES, GS, and SS register #define's in /usr/include/sys/regset.h.
Again, I just added a few more #undef's:
#ifdef ES
#undef ES
#endif
#ifdef GS
#undef GS
#endif
#ifdef SS
#undef SS
#endif
I'm really wondering why sys/regset.h is being #include'd in just about everything in the AWS SDK.
5
Same problem in aws-sdk-cpp/aws-cpp-sdk-waf-regional/include/aws/waf-regional/model/GeoMatchConstraintValue.h. Same fix, add:
#ifdef ES
#undef ES
#endif
#ifdef GS
#undef GS
#endif
#ifdef SS
#undef SS
#endif
Note that compiling on SPARC hardware means the #define value from sys/regset.h will be completely different, and any errors will be completely different.
6
The file aws-sdk-cpp/aws-cpp-sdk-core-tests/utils/FileSystemUtilsTest.cpp incorrectly assumes the POSIX NAME_MAX value is defined. Per the POSIX Pathname Variable Values standard (bolding mine):
Pathname Variable Values
The values in the following list may be constants within an
implementation or may vary from one pathname to another. For example,
file systems or directories may have different characteristics.
A definition of one of the symbolic constants in the following list
shall be omitted from the <limits.h> header on specific
implementations where the corresponding value is equal to or greater
than the stated minimum, but where the value can vary depending on the
file to which it is applied. The actual value supported for a specific
pathname shall be provided by the pathconf() function.
Again: the "definition ... shall be omitted ... where the value can vary".
The AWS code wrongly assumes NAME_MAX must be #define'd.
I just hardcoded a value of 255 to get past this point, although using something like _POSIX_NAME_MAX or _XOPEN_NAME_MAX is probably better.
7
File aws-sdk-cpp/ws-cpp-sdk-core-tests/http/HttpClientTest.cpp seems to be incorrectly assuming a std::shared_ptr will be 8 bytes. This question and answer provides a good example of how that's wrong.
I just ignored this error as it's just a test and continued with gmake -i, which completed successfully outside of this one error.

When importing Nim module for Lua bindings, error shows: "could not load: lua(|5.1|5.0).dll"

I'm new to the Nim programming language, and coming from a Lua background, it excited me to find out that there is a module for adding Lua bindings to Nim.
I installed Nimble (Nim's package manager) for Windows and executed "nimble install lua" to download and install the correct module. Upon trying to import it and compile the source, this happened:
C:\Users\Ashley\Desktop\Stuff\Coding\Nim\Projects\LuaTest>nim c -r "C:\Users\Ashley\Desktop\Stuff\Coding\Nim\Projects\LuaTest\main.nim"
Hint: system [Processing]
Hint: main [Processing]
Hint: lua [Processing]
CC: main
CC: lua_lua
Hint: [Link]
Hint: operation successful (10698 lines compiled; 1.262 sec total; 16.163MB; Debug Build) [SuccessX]
could not load: lua(|5.1|5.0).dll
Error: execution of an external program failed: 'c:\users\ashley\desktop\stuff\coding\nim\projects\luatest\main.exe '
I have Lua 5.1 already installed with the proper entries in PATH. It's located in Program Files (x86). The directory contains a dll called lua5.1.dll. I tried looking up the error on Google, but there were no results that helped. What could be the problem?
On Windows you can put the library at the same place as the generated binary. In this case the file should be called lua.dll, lua5.1.dll or lua5.0.dll. Also make sure that the library and binary are both for the same system architecture, either x86 (32bit) or x86-64 (64bit).

regsvr32 fails for simple freepascal COM dll

I'm completely new to free-pascal and I try to implement a simple dll that should register a COM class.
Unfortunately I could only find little information about COM Programming for freepascal. Thus I hope that someone here can give me some hints or even a link to some examples.
So here is what I did:
my operating system is Windows 7 64 bit
downloaded and installed Lazarus 32bit version
Version #: 1.2.6
Date: 2014-10-11
FPC: Version 2.6.4
SVN Revision: 46529
i386-win32-win32/win64
installed the ActiveX package in Lazarus
made a new project - type Library with a simple TAutoObject and a default TAutoObjectFactory for the COM registration: source code included after this description
build the dll
use regsvr32.exe to register my dll --> this fails with
"make sure the binary is stored at the specified path ..."
Invalid access to memory location.
then I tried to change the default project options:
under Compiler Options - Config and Target, I set
Target OS: Win32
Target CPU family: i386
still the same error occurs
Project source
library LazarusSimpleComRegTest;
{$mode objfpc}{$H+}
uses
Classes,
{ you can add units after this }
ComServ, MyComObj;
exports
DllGetClassObject,
DllCanUnloadNow,
DllRegisterServer,
DllUnregisterServer;
end.
MyComObj Unit:
unit MyComObj;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, ComObj;
const
CLASS_Plugin: TGUID = '{5E020FB0-B593-4ADF-9288-801C2FD432CF}';
type
TPlugin = class(TAutoObject)
end;
implementation
uses ComServ;
initialization
TAutoObjectFactory.Create(ComServer, TPlugin, CLASS_Plugin,
ciMultiInstance, tmApartment);
end.
I think the main problem was, that I did not include the type library as a resource in my dll file: Now it works fine.
I've made a very basic and simple working example on git-hub with some basic documentation:
lazarus-com-example

How to programmatically determine a Cocoa plugin bundle's garbage collection settings?

On Mac OS X using Objective-C 2, plugin bundles can be compiled with one of three garbage collection settings:
Not Supported
Supported (-fobjc-gc)
Required (-fobjc-gc-only)
How can one programmatically query a compiled plugin bundle to determine which of these three settings was used?
It's part of the __OBJC segment but I don't know of any API that exposes it.
Garbage collected:
cristi:tmp diciu$ otool -v -o ./a.out
./a.out:
Contents of (__DATA,__objc_classrefs) section
00000001000010b0 0x0
Contents of (__DATA,__objc_imageinfo) section
version 0
flags 0x6 OBJC_IMAGE_SUPPORTS_GC
Non garbage collected:
cristi:tmp diciu$ otool -v -o ./a.out
./a.out:
Contents of (__DATA,__objc_classrefs) section
00000001000010b0 0x0
Contents of (__DATA,__objc_imageinfo) section
version 0
flags 0x0
The runtime does this using private functions: see gc_enforcer and it's use of * _objcInfoRequiresGC*
Following the answer from diciu, you can use the Mach-O API. You have to parse the segments contained in the binary file and search for the __OBJC one; the segment_command structure allows an access to the segment's flags.
You can also take a look at the ClassDump project. It has a pretty complete Mach-O parser.
It's probably easiest to just try and load the bundle using NSBundle's -loadAndReturnError: method. If the bundle won't load due to the fact that its GC settings are different to those in your app, you'll get an NSExecutableRuntimeMismatchError.