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

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
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

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
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
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

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

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
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

Vincent Snijders | 16 May 2013 19:31
Picon

Re: [FPC 0024437]: can not build RTL with 2.7.1 compiler





----------------------------------------------------------------------
 (0067718) Vincent Snijders (manager) - 2013-05-16 18:39
 http://bugs.freepascal.org/view.php?id=24437#c67718
----------------------------------------------------------------------
That compiler is too old, it should be the same revision as the RTL source.

----------------------------------------------------------------------
 (0067719) Jonas Maebe (manager) - 2013-05-16 18:57
 http://bugs.freepascal.org/view.php?id=24437#c67719
----------------------------------------------------------------------
No, the starting compiler is too new. Compiling a new compiler directly using an
old compiler and old RTL (in order to then compile the new RTL with the
resulting compiler) is not supported either.

The only procedure that has always been supported and always only will be
supported is a "make all" in the top level FPC directory starting with the
latest release.


Compiling the RTL of revision 24514 with a compiler of revision 24514 is supported, isn't it?

Vincent
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
vfclists . | 16 May 2013 15:27
Picon

Examples of tiOPF logging in the wild


Are there some examples of using tiOPF logging besides those in the demos?


I want to use tiLogToGUI, but I am not happy with the amount of screen space it takes. Is there some way it can be adapted or themed to be tidier or smaller?

The code gives the impression that it can be embedded or extended in another form or is
that a misconception on my part?

--
Frank Church

=======================
http://devblog.brahmancreations.com
_______________________________________________
fpc-pascal maillist  -  fpc-pascal@...
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Gmane