headers
Anthony Walter | 26 May 2013 09:35
Picon
Gravatar

Undefined symbols. Help!

Can someone point me in the right direction towards solving this problem?

I built a static libraries on Linux based on some open source c and h files. I can compile things fine with gcc/mingw-265 and use ar to turn the object files into a static lib (libtess.a). The problem is when I try to compile on Windows with the static lib I get the linking errors below when I try to compile and exe which uses the functions I'm importing:

Error: Undefined symbol: _malloc
Error: Undefined symbol: _free
Error: Undefined symbol: __assert
Error: Undefined symbol: __setjmp3
Error: Undefined symbol: _longjmp
Error: Undefined symbol: _realloc
Fatal: There were 6 errors compiling module, stopping

In one of my packages I am doing this:

{$linklib tess} // libtess.a compiled using i686-mingw-w64-gcc on Linux


On Linux I ran an nm command in the mingw-w64 folder and found those functions in libmsvcrt.a and libmsvcr100.a ... so I copied those files to my windows box and tried linking with each one (separately {$linklib msvcrt} for example) as well, but I still get the same linking errors. I also tried linking in ...

{$linklib user32}
{$linklib kernel32}
{$linklib msvcr100}
{$linklib mingw32}
{$linklib tess}

I'd really appreciate it if anyone could help me better understand how to work with static libraries compiled on Linux and linked on Windows.

Thanks.

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 0 comments |
headers
Reinier Olislagers | 25 May 2013 14:25
Picon

fcl-res: using resource embedded in exe

Hi list,

I've noticed some code of mine using resources needed the windows unit
(to get RT_RCDATA), Iand therefore wasn't cross-platform.

Tried rewriting using fcl-res, which seems to work ok at least on Windows:
uses
  ,resource
  //resource readers
  ,resreader, coffreader, winpeimagereader, elfreader, machoreader
  //misc
  ,elfconsts, cofftypes, machotypes;
...
    Resources:=TResources.Create;
    ResourceStream:=TMemoryStream.Create;
    try
// ====>>>>>> problem here
      Resources.LoadFromFile(Paramstr(0)); //load from exe. Isn't there
a more elegant way of doing this?
// ====>>>>>> end of problem
      for ResourceCounter:=0 to Resources.Count-1 do
      begin
        // Make sure we get the correct resource (must match .rc values):
        if (Resources[ResourceCounter]._Type.Name='RCDATA') and
          (Resources[ResourceCounter].Name.Name='SQLSCRIPT') then
        begin
          ResourceStream.CopyFrom(Resources[ResourceCounter].RawData,
            Resources[ResourceCounter].RawData.Size);
          break;
        end;
      end;
      if ResourceStream.Size=0 then
        raise Exception.Create('Cannot load SQL script as a resource
from the executable.');

In the code above, I'm loading the resource from the executable.
However, Paramstr(0) is not reliable on all platforms.
Is there a better way of doing this?

Thanks,
Reinier
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 0 comments |
headers
Mark Morgan Lloyd | 24 May 2013 12:14
Picon

Re: FPC / Lazarus install on Fedora 18

Jonas Maebe wrote:
> I understand this is well-intended, but please don't overdo it. The 
> person apologised and acknowledged what his mistake was. Adding a long 
> extra message on this topic does not really add anything useful to the 
> discussion and does not help with creating a friendly atmosphere either. 
> In general comments about such issues, if posted to the list, should 
> only be made by the moderator in any case.

My apologies, but I was trying to confirm that there was, in fact a 
header and to show that it had been part of the email standards for a 
very long time. It's nothing new, it's not specific to mailing list 
managers, and it's definitely not specific to this mailing list.

I was definitely not trying to "get at" the poster who had inadvertently 
triggered somebody else's outrage, particularly since he had realised 
and pointed out what he'd done wrong. However I find the number of 
complaints I see about this behaviour irritating- it's difficult enough 
to keep abreast of things as it is.

--

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 0 comments |
headers
Bruce Tulloch | 23 May 2013 14:10

CThreads problem when cross-compiling to ARM/RPi.

Starting with a simple test program arm-test.pas:

program test;
begin
  writeln('DATE ',{$i %DATE%});
  writeln('FPCTARGET ',{$i %FPCTARGET%});
  writeln('FPCTARGETCPU ',{$i %FPCTARGETCPU%});
  writeln('FPCTARGETOS ',{$i %FPCTARGETOS%});
  writeln('FPCVERSION ',{$i %FPCVERSION%});
end.

I can cross-compile:

Free Pascal Compiler version 2.7.1 [2013/05/20] for arm
Copyright (c) 1993-2013 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling arm-test.pas
Assembling test
Linking arm-test
8 lines compiled, 0.1 sec

successfully producing this:

arm-test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, stripped

which when executed produces:

DATE 2013/05/23
FPCTARGET arm
FPCTARGETCPU arm
FPCTARGETOS Linux
FPCVERSION 2.7.1

All good, the ARM cross-compiler is working.

However, if I simply add this uses clause:

uses
  cthreads;

the program compiles fine but fails when linking:

Linking arm-test-threads
/usr/local/lib/fpc/2.7.1/
units/arm-linux/rtl/cthreads.o: In function `CTHREADS_$$_LOADPTHREADS$$BOOLEAN':
cthreads.pp:(.text.n_cthreads_$$_loadpthreads$$boolean+0xc): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlopen.o): In function `dlopen':
(.text+0xc): undefined reference to `__dlopen'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlclose.o): In function `dlclose':
(.text+0x0): undefined reference to `__dlclose'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dlsym.o): In function `dlsym':
(.text+0xc): undefined reference to `__dlsym'
/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf//libdl.a(dladdr.o): In function `dladdr':
(.text+0x0): undefined reference to `__dladdr'
An error occurred while linking arm-test-threads

When compiling the same code native (x86_64) or cross compiled to Linux i386, this does not happen (i.e the program links and executes fine). The ARM linux system against which I'm linking is raspbian for RPi.

The relevant compiler configuration is:

#IFDEF CPUARM
-Xd
-k--sysroot=/usr/local/opt/chroot/raspbian/rootfs
-Fl/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf
-Fl/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf
-FD/usr/local/opt/binutils/bin
-XP$FPCTARGET-
#ENDIF

What am I doing wrong?

Thanks, Bruce.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 18 comments |
headers
Reinier Olislagers | 23 May 2013 12:20
Picon

Moving packages\fcl-res docs to main fpcdocs?

Noticed that fcl-res has documentation in an XML subfolder of
$(fpcdir)\packages\fcl-res

Shouldn't these be moved into the general fpcdocs repository (and
generated as part of the fcl docs)?
(I know that not all xml files will apply to all platforms; IMO it's
easier here to indicate some doc is specific to one platform/file format
and just include everything... makes devs more aware of cross-platform
possibilities/issues)

Regards,
Reinier
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 4 comments |
headers
Bruce Tulloch | 23 May 2013 07:38

How does FPC calculate linker search paths upon -XP?

Using FPC 2.7.1 I'm cross-compiling from x86_64 to ARM/RPi and have specified:

-XR/usr/local/opt/chroot/raspbian/rootfs

This produces a link.res file that includes the following:

SEARCH_DIR("/usr/local/opt/chroot/raspbian/rootfs/usr/lib/arm-linux-gnueabihf/")
SEARCH_DIR("/usr/local/opt/chroot/raspbian/rootfs/lib/")
SEARCH_DIR("/usr/local/opt/chroot/raspbian/rootfs/usr/lib/")

but it DOES NOT include this line:

SEARCH_DIR("/usr/local/opt/chroot/raspbian/rootfs/lib/arm-linux-gnueabihf/")

despite the fact the ld.so configuration file:

/usr/local/opt/chroot/raspbian/rootfs/etc/ld.so.conf.d/arm-linux-gnueabihf.conf

specifies both paths as:

# Multiarch support
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf

What am I doing wrong?

Thanks, Bruce
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 3 comments |
headers
silvioprog | 23 May 2013 03:11
Picon
Gravatar

PostgreSQL and error codes

Hello,

How to get the error code of a data base error? I'm using the PostgreSQL. The full list of all erros is:

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 2 comments |
headers
Felipe Monteiro de Carvalho | 21 May 2013 17:47
Picon

Android JNI failing in Galaxy S4

Hello,

I know that some other people here are developing Android JNI apps.

For me it has worked perfectly so far, but as we just got a Galaxy S4
in the office I thought of testing my app there and boom =( It crashes
at the startup:

I/True Democracy( 8624): Trying to load libtruedemocracy.so
D/dalvikvm( 8624): Trying to load lib
/data/app-lib/com.felipe.truedemocracy-1/libtruedemocracy.so
0x421fadc8
W/libc    ( 8624): WARNING: generic atexit() called from legacy shared library
D/dalvikvm( 8624): Added shared lib
/data/app-lib/com.felipe.truedemocracy-1/libtruedemocracy.so
0x421fadc8
I/truedemocracy( 8624): JNI_OnLoad called
I/truedemocracy( 8624): Reading our Activity Class
E/dalvikvm( 8624): ERROR: couldn't find native method
E/dalvikvm( 8624): Requested:
Lcom/felipe/truedemocracy/TrueDemocracy;.GetHistoricalInflationCount:()I
F/truedemocracy( 8624): javaEnvRef^.RegisterNatives failed
I/truedemocracy( 8624): JNI_OnLoad finished
D/qdmemalloc(  217): ion: unmap_buffer base:0x0 size:8355840 offset:0 fd:49
D/qdmemalloc(  217): ion: unmap_buffer base:0x0 size:4096 offset:0 fd:78
D/qdmemalloc(  217): ion: unmap_buffer base:0x0 size:8355840 offset:0 fd:66
D/qdmemalloc(  217): ion: unmap_buffer base:0x0 size:4096 offset:0 fd:67
W/dalvikvm( 8624): No implementation found for native
Lcom/felipe/truedemocracy/TrueDemocracy;.Translations_TranslateToISO639_2_Code:(Ljava/lang/String;Ljava/lang/String;)V
D/AndroidRuntime( 8624): Shutting down VM
W/dalvikvm( 8624): threadid=1: thread exiting with uncaught exception
(group=0x410b8ac8)
D/Sensorhubs(  228): readContextData: 1, 1, 14, 1
D/SensorHubManager(  724): onGetSensorHubDataLocked: library = 1, 1, 14, 1
D/CAE     (  724): onGetSensorHubData(SensorHubParserProvider.java:66)
- onGetSensorHubData Event [event buffer len :4]
I/CAE     (  724): parse(SensorHubParserProvider.java:129) - buffer size = 4
I/CAE     (  724): parse(SensorHubParserProvider.java:140) - 1, 1, 14, 1,
D/qdoverlay(  217): Unset pipe=VG0 dpy=0; Unset pipe=VG1 dpy=0; Unset
pipe=RGB1 dpy=0;
D/CAE     (  724): display(ContextProvider.java:430) -
================= FLIP_COVER_ACTION =================
V/WindowManager(  724): Window{42b3a138 u0
Keyguard}mOrientationRequetedFromKeyguard=false
E/AndroidRuntime( 8624): FATAL EXCEPTION: main
E/AndroidRuntime( 8624): java.lang.UnsatisfiedLinkError: Native method
not found: com.felipe.truedemocracy.TrueDemocracy.Translations_TranslateToISO639_2_Code:(Ljava/lang/String;Ljava/lang/String;)V
E/AndroidRuntime( 8624):        at
com.felipe.truedemocracy.TrueDemocracy.Translations_TranslateToISO639_2_Code(Native
Method)
E/AndroidRuntime( 8624):        at
com.felipe.truedemocracy.TrueDemocracy.onCreate(TrueDemocracy.java:632)
E/AndroidRuntime( 8624):        at
android.app.Activity.performCreate(Activity.java:5250)
E/AndroidRuntime( 8624):        at
android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1097)
E/AndroidRuntime( 8624):        at
android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2210)
E/AndroidRuntime( 8624):        at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2296)
E/AndroidRuntime( 8624):        at
android.app.ActivityThread.access$700(ActivityThread.java:151)
E/AndroidRuntime( 8624):        at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:1281)
E/AndroidRuntime( 8624):        at
android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 8624):        at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 8624):        at
android.app.ActivityThread.main(ActivityThread.java:5293)
E/AndroidRuntime( 8624):        at
java.lang.reflect.Method.invokeNative(Native Method)
E/AndroidRuntime( 8624):        at
java.lang.reflect.Method.invoke(Method.java:511)
E/AndroidRuntime( 8624):        at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
E/AndroidRuntime( 8624):        at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
E/AndroidRuntime( 8624):        at dalvik.system.NativeStart.main(Native Method)

Any ideas?

I am not doing anything unusual, and exact same APK works fine in HTC
Wildfire, Xperia Mini, Galaxy Nexus, etc, etc.

=(

it runs JNI_onCreate to the end, so at least code is being executed.

The routine that it complains about is declared correctly:

procedure Java_com_felipe_truedemocracy_TrueDemocracy_Translations_TranslateToISO639_2_Code(
  env:PJNIEnv; this:jobject; AISOCode, ACountry: jstring); cdecl;

And is correct in the structure:

   (name:'Translations_TranslateToISO639_2_Code';
    signature:'(Ljava/lang/String;Ljava/lang/String;)V';
    fnPtr: <at> Java_com_felipe_truedemocracy_TrueDemocracy_Translations_TranslateToISO639_2_Code;),

And is correct in RegisterNative:

  // Register Pascal exported calls
  if javaEnvRef^^.RegisterNatives(javaEnvRef, javaActivityClass,
 <at> NativeMethods[0],length(NativeMethods))<0 then
  begin
    __android_log_write(ANDROID_LOG_FATAL, 'truedemocracy',
'javaEnvRef^.RegisterNatives failed');
  end;

My only idea at the moment is to do the static export too... maybe
that will work, lets see.

--

-- 
Felipe Monteiro de Carvalho
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 18 comments |
headers
Reinier Olislagers | 22 May 2013 08:06
Picon

FPC trunk r224549 needs more incantations?

r24549 | joost | 2013-05-21 21:58:14 +0200 (di, 21 mei 2013) | 1 line

 * Removed unused unit jarparamparser.pas

Perhaps some (fp(c))make regeneration or something?

Building it I see:
make.exe[3]: Leaving directory `C:/development/fpctrunk/utils/fpcres'
make.exe[3]: *** No rule to make target `jarparamparser.pas', needed by
`fpcjres
.exe'.  Stop.
make.exe[2]: *** [fpcres_all] Error 2
make.exe[2]: Leaving directory `C:/development/fpctrunk/utils'

Thanks,
Reinier
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 4 comments |
headers
Anthony Walter | 18 May 2013 03:41
Picon
Gravatar

Compiler bug with managed type not being initialized correctly

I just filed a bug having to do with a managed type (I am using an interface in my code) not being properly initialized when stored in a record's private section:


I marked the issue as major since I thought this kind of issue (managed types slipping through initialization should never happen. If anyone want more clarity on this issue let me know. As an added note, if this situation causes an interface to not be initialized,it probably also has problems with finalization that need being looked at as well.

Managed types described (as best as I could find):

_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 1 comment |
headers
leledumbo | 18 May 2013 02:55
Picon
Favicon
Gravatar

-v to show function call frequency

Is there any -v (or any other option) to show summary of function call
frequency (in term of appearance in source code, not actual function call)?
i.e. something like:

program A:
routine        times called
--------------------------------
function1      10
procedure1     5
function2       1

units B:
routine        times called
--------------------------------
procedure1     3
procedure2     2

--
View this message in context: http://free-pascal-general.1045716.n5.nabble.com/v-to-show-function-call-frequency-tp5714839.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Permalink | Reply | 0 comments |

Gmane