View Issue Details

IDProjectCategoryView StatusLast Update
0032367FPCCompilerpublic2020-04-08 19:08
ReporterMartin Schreiber Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
OSLinux 
Product Version3.0.2 
Summary0032367: "so.n" part removed in "external" clause
Description"so.n" part in "external" clause is removed in library name which makes it impossible to pick up the correct library version in a binding unit.

For example a binding unit made for the version with the SONAME "libX11.so.6",
"
function XLoadQueryFont(para1:PDisplay; para2:Pchar):PXFontStruct;
                                      cdecl; external 'libX11.so.6';
"
inserts
"
INPUT(
-lX11
)
"
in the linker script -> the filename is "libX11.so" which is not available by default and if available it could be a wrong version and therefore puts the wrong SONAME into the binary.
Correctly
"
INPUT(
-l:libX11.so.6
)
"
should be in linker script instead. If you want to keep the erroneous behaviour treat a leading colon as start of a filename as ld does:
"
function XLoadQueryFont(para1:PDisplay; para2:Pchar):PXFontStruct;
                                      cdecl; external ':libX11.so.6';
"
would insert
"
INPUT(
-l:libX11.so.6
)
"
in linker script.
man ld:
"
       -l namespec
       --library=namespec
           Add the archive or object file specified by namespec to the list of
           files to link. This option may be used any number of times. If
           namespec is of the form :filename, ld will search the library path
           for a file called filename, otherwise it will search the library
           path for a file called libnamespec.a.
[...]
"
See also
https://www.mail-archive.com/mseide-msegui-talk%40lists.sourceforge.net/msg11386.html
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Activities

Marco van de Voort

2017-09-03 21:28

manager   ~0102622

IMHO such mapping should not be in the source, that will only lead to wars about what form should be default in precompiled code.

Instead the external name should be considered a tag, and it should be possible to specify per application what it should map to. (static or not, or a different name). This was the idea of the -XL switches originally.

Martin Schreiber

2017-09-04 07:26

reporter   ~0102625

Don't you think it is necessary to guarantee that the linked in library version is compatible to the version for which the binding unit has been made for on all build environments a Free Pascal binding unit will be compiled, independently of the version of the installed -devel-package in the actual build system?
Don't you think that the authors of the binding units should have the possibility to define the SONAME source in binding units because the authors actually know for which major version they made the bindings?
They don't need to do so if they don't want to but Fee Pascal should allow it.
Overrides by -XL could be made in addition.

Marco van de Voort

2017-10-13 13:01

manager   ~0103404

No I don't think that is a good idea at all. In rare cases it might, but it is an extremely exceptional case.

And no, I don't think each and every option should be set in source. An author cannot always foresee which future versions are compatible or not, and it only causes a lot of frustration when a distro moves to a (slightly) newer version.

Moreover, one could have specific tags for major versions of libraries, but specifying the exact one will only lead to pain.

Thaddy de Koning

2017-11-16 11:29

reporter   ~0104131

Note this can be solved by ln. Create a symlink to the version you need.

Martin Schreiber

2018-01-12 10:20

reporter   ~0105688

@Marco: please note that I wrote about *major versions* not exact file.
The "extremely exceptional case" actually is every common Linux distribution where devel-packages are not installed by default and normal users of applications made with Free Pascal should not be obligated to know how to install the necessary devel-packages. Not to mention what happens if they install the wrong devel-version...

Martin Schreiber

2018-01-12 13:10

reporter   ~0105692

Sorry, I intermixed things in my last comment, but it does not change what I wrote before.
Anyway, forget it. I long lost hope that anything in Free Pascal can be changed in a pragmatic manner for the benefit of its users if it is not dictated by Delphi.

Thaddy de Koning

2018-01-12 13:10

reporter   ~0105693

Normal users of an FPC compiled binary do not need devel packages.
It is YOUR task to provide any dependencies.

Marco van de Voort

2018-01-12 19:35

manager   ~0105719

Martin: having hardcoded names only causes frustration, specially if you have two different groups (e.g. one on LTS, and one on a current one)

You can still add hardcoded mapping from tag to a "likely" .so.x(.y) in the fpc.cfg that way. The only, but crucial difference is that you don't have to recompile source (or have two ppu distros) to change the file. Then you just need to change the fpc.cfg.

Please try to keep a somewhat open mind.

Martin Schreiber

2018-01-13 06:40

reporter   ~0105725

I fear you still don't understand the issue. It's about that the author of the binding unit needs the possibility to define the SONAME (= API compatible major version) which will be picked up if the binding unit will be compiled on another machine than the author's.
I am sure it can be done in a way that the feature can be used but nobody is forced to use it.
Do you know how Kylix and the new Delphi for Linux handles it?

Marco van de Voort

2018-02-16 21:06

manager   ~0106407

Last edited: 2018-03-04 18:52

View 2 revisions

I fear you still don't understand the issue:

- The soname is determine when linking the final (executable) binary or library
- the binding unit might not be compiled on the same machine, and be used on multiple machines and across multiple distro versions, flavours and spins.

Hence whatever designation used in the binding unit is a placeholder, so that on the definitive link system dependent settings can replace the placeholder with the real soname, without modifying the binding unit and then recompiling it and its dependencies.. This was the whole idea behind the -XL* parameters.

Delphi for Linux don't care about distribution durability, they force you to a subscription model nowadays, and support a limited number of distributions. Kylix did that latter already too.

fredvs

2018-02-20 18:09

reporter   ~0106489

> Kylix did that latter already too.

Here content of lib_namesh.inc used by Kylix.
You will see than the so-names include the ".number" and Kylix do not strip it later:

const

   LD_LINUX_SO = 'ld-linux.so.2';
   LD_SO = 'ld-linux.so.2';
   LIBANL_SO = 'libanl.so.1';
   LIBBROKENLOCALE_SO = 'libBrokenLocale.so.1';
   LIBCRYPT_SO = 'libcrypt.so.1';
   LIBC_SO = 'libc.so.6';
   LIBDB1_SO = 'libdb1.so.2';
   LIBDB2_SO = 'libdb2.so.3';
   LIBDL_SO = 'libdl.so.2';
   LIBM_SO = 'libm.so.6';
   LIBNOVERSION_SO = 'libNoVersion.so.1';
   LIBNSL_SO = 'libnsl.so.1';
   LIBNSS_COMPAT_SO = 'libnss_compat.so.2';
   LIBNSS_DNS6_SO = 'libnss_dns6.so.2';
   LIBNSS_DNS_SO = 'libnss_dns.so.2';
   LIBNSS_FILES_SO = 'libnss_files.so.2';
   LIBNSS_HESIOD_SO = 'libnss_hesiod.so.2';
   LIBNSS_LDAP_SO = 'libnss_ldap.so.2';
   LIBNSS_NISPLUS_SO = 'libnss_nisplus.so.2';
   LIBNSS_NIS_SO = 'libnss_nis.so.2';
   LIBPTHREAD_SO = 'libpthread.so.0';
   LIBRESOLV_SO = 'libresolv.so.2';
   LIBRT_SO = 'librt.so.1';
   LIBTHREAD_DB_SO = 'libthread_db.so.1';
   LIBUTIL_SO = 'libutil.so.1';

fredvs

2018-02-21 18:14

reporter   ~0106518

Here link to the Kylix run-time library given for the developers:
http://kylixlibs.sourceforge.net

You may see that, curiously, Borland did use soname with .releasenumber extensions for his developer packages: (example: bplrtl.so.6.9, bplvisualclx.so.6.9, ...).

Could it be that there is a confusion with other languages, like Java?

Java (and Android of course) do not like more than ".so" as extension for libraries.
For example, in a Android apk, libraries with only "*.so" are accepted in the /libs folder.

This because of some limitation of Java and his "dot (.)" usage.

But why to impose that limitation to fpc? (fpc has not that limitation-problem).

fredvs

2018-02-21 19:43

reporter   ~0106520

> Hence whatever designation ...

Here a **CONCREATE** example in the real world:

Library PortAudio.
http://www.portaudio.com

There are 2 versions: V18 and V19 that use **totally* different headers.
Both versions are distributed nearly in all Linux/FreeBSD distros.

The soname of PortAudio V18 is:
libportaudio.so

The soname of PortAudio V19 is:
libportaudio.so.2

With your "stripped" code, people are unable to load PortAudio V19.

PS: For me it is not a problem anymore, I use dynamic loading with LoadLibrary().

PS2: Please do not touch the way LoadLibrary() works, it is perfect like it is now.

Florian

2018-03-04 18:49

administrator   ~0106862

I think the proposal not to mess with the filename if it is preceeded by : sounds reasonable to me.

Marco van de Voort

2018-03-04 18:53

manager   ~0106864

Till the next modifier comes along.

Martok

2018-03-05 00:05

reporter   ~0106871

Last edited: 2018-03-05 01:15

View 2 revisions

It may be useful to know that there is a comment in compiler/systems/t_linux.pas:1586 specifically declaring the behavior asked for here as the intended one (strip .so, don't strip so.n; this is also what actually happens in the referenced functions).
The internal linker appears to handle that correctly in AddLibraryStatement, but all of the external linkers (see t_linux.pas:550, other targets use copypasta) strip the extension completely.

So: no need for special handling of colons, it's actually all already there, right up to linker script generation.

Patch to do what is documented would be simply replacing t_linux.pas:558 "Delete(S,i,255);" with "Insert(':',s,1);" - if the extension survives to that point, is is followed by a version number and needs to be literal.

fredvs

2020-04-04 17:58

reporter   ~0121905

Last edited: 2020-04-04 18:28

View 3 revisions

Happy birthday little bug, more than 3 years old now.

Uploaded fixed /compiler/link.pas and /compiler/systems/t_linux.pas.

Deeply tested, did not find any problems.
The only thing that it does is to solve many things.

Here part of result of link.res produced by -ls parameter:

INPUT(
-lpthread
-l:libc.so
-l:libX11.so.6
-l:libdl.so
-l:libpthread.so
-l:librt.so
-lm
)

And it is perfectly accepted by the linker ld.

Fre;D

t_linux.pas.zip (15,710 bytes)
link.pas.zip (11,366 bytes)

fredvs

2020-04-05 13:22

reporter   ~0121937

Last edited: 2020-04-05 13:23

View 2 revisions

@ Marcov:

> Till the next modifier comes along.

I offer you 10 knoedels met mayonaise if you can find a problem with the fixed files.

I uploaded link.pas with some more checkup.
The t_linux.pas is the same as previous post.

Fre;D

link.pas-2.zip (11,439 bytes)
t_linux.pas-2.zip (15,710 bytes)

fredvs

2020-04-06 13:17

reporter   ~0121961

Last edited: 2020-04-06 13:49

View 2 revisions

***PING***

I find very sad that because of personal feelings (Marcov did not like Martin and hates me), to deprive other people of the benefit of fix (even if Florian agreed).

That bug annoy people since age, the fix is clean and dont break any compatibility.

Fre;D

Bi0T1N

2020-04-06 14:19

reporter   ~0121963

It would be easier if you create a patch instead of uploading your whole files, see https://wiki.freepascal.org/Creating_A_Patch

Marco van de Voort

2020-04-06 14:35

manager   ~0121965

I didn't dislike Martin, and didn't hate you. Till now :-)

fredvs

2020-04-06 14:40

reporter   ~0121966

Last edited: 2020-04-06 16:49

View 4 revisions

Liar.
And me, till now, i dont dislike you and after now too.

[EDIT]
I offered you 10 knoedels met mayonaise, you did not answer to the proposition.
So sure that you must hate me.

[EDIT2]
And you have now the opportunity to prove that in fpc team, they apply fixes even from people that they hate.

fredvs

2020-04-06 14:46

reporter   ~0121967

> It would be easier if you create a patch instead of uploading your whole files, see https://wiki.freepascal.org/Creating_A_Patch

Thanks Bi0T1N but the problem here is not the patch, it is elsewhere.

Sven Barth

2020-04-06 17:49

manager   ~0121977

Last edited: 2020-04-06 17:50

View 2 revisions

Marco is not working on the compiler, so it's unlikely that he'll commit a patch for it.

Also please provide a patch. Full files are unnecessary work for us and will be ignored far more likely (and as a bonus I can open a patch here in the bug tracker and look at it without downloading it).

Note: I'm not saying that I'll commit it either, but that's no reason to make it harder for us.

fredvs

2020-04-06 18:11

reporter   ~0121979

Hello Sven.
OK, I will add a patch if you prefer.

> Note: I'm not saying that I'll commit it either,

That is not really the problem, maybe somethings could be changed.
The problem is to not systematically be against any change.

And I agree this change is a BIG change for Unix developers.
Maybe the biggest change since the first release of fpc.

The code in link.pas is clearly out of date.
It seems that it was done by people that ignore the ":" trick used by the linker ld.

Please read carefully the explanation of Martin in begin of topic.

Fre;D

fredvs

2020-04-06 18:26

reporter   ~0121980

This was changed in t_linux.pas line 603 and comes from Martok advice:

if (s<>'c') or reorder then
                  begin
                    i:=Pos(target_info.sharedlibext,S);
                    if i>0 then
                    // Delete(S,i,255); // this commented
                    Insert(':',s,1); // change with this ---> line 603
                    Add('-l'+s);
                    libraryadded:=true;
                  end
                 else
                   linklibc:=true;

And this in link.pas line 510 :

Procedure TLinker.AddSharedLibrary(S:TCmdStr);
      begin
        if s='' then
          exit;
        { remove prefix 'lib' }
  // if Copy(s,1,length(target_info.sharedlibprefix))=target_info.sharedlibprefix then
  // Delete(s,1,length(target_info.sharedlibprefix));
        { remove extension if any }
  // if Copy(s,length(s)-length(target_info.sharedlibext)+1,length(target_info.sharedlibext))=target_info.sharedlibext then
  // Delete(s,length(s)-length(target_info.sharedlibext)+1,length(target_info.sharedlibext)+1);
      
          // changed with this:
        if (Copy(s,1,length(target_info.sharedlibprefix))=target_info.sharedlibprefix)
        and (system.pos(target_info.sharedlibext,s) = 0) then
         Delete(s,1,length(target_info.sharedlibprefix));
            
        SharedLibFiles.Concat(S);
      end;

The same was done for Procedure TLinker.AddSharedCLibrary(S:TCmdStr);

Are you really sure that you need a patch (I am terrified to do this)?

fredvs

2020-04-06 19:43

reporter   ~0121983

Do you Git?

Is it ok If I do a pull request to?:
https://github.com/graemeg/freepascal

fredvs

2020-04-06 22:03

reporter   ~0121986

OK, patch added.
so_n_fix.diff (2,808 bytes)   
Index: compiler/link.pas
===================================================================
--- compiler/link.pas	(révision 44618)
+++ compiler/link.pas	(copie de travail)
@@ -508,17 +508,14 @@
       begin
         if s='' then
           exit;
-        { remove prefix 'lib' }
-        if Copy(s,1,length(target_info.sharedlibprefix))=target_info.sharedlibprefix then
-          Delete(s,1,length(target_info.sharedlibprefix));
-        { remove extension if any }
-        if Copy(s,length(s)-length(target_info.sharedlibext)+1,length(target_info.sharedlibext))=target_info.sharedlibext then
-          Delete(s,length(s)-length(target_info.sharedlibext)+1,length(target_info.sharedlibext)+1);
-        { ready to be added }
+           { remove prefix 'lib' only if no extension }
+        if (Copy(s,1,length(target_info.sharedlibprefix))=target_info.sharedlibprefix)
+        and (system.pos(target_info.sharedlibext,s) = 0) then
+         Delete(s,1,length(target_info.sharedlibprefix));
+            
         SharedLibFiles.Concat(S);
       end;
 
-
     Procedure TLinker.AddStaticLibrary(const S:TCmdStr);
       var
         ns : TCmdStr;
@@ -532,22 +529,18 @@
         StaticLibFiles.Concat(ns);
       end;
 
-
     Procedure TLinker.AddSharedCLibrary(S:TCmdStr);
       begin
         if s='' then
           exit;
-        { remove prefix 'lib' }
-        if Copy(s,1,length(target_info.sharedclibprefix))=target_info.sharedclibprefix then
-          Delete(s,1,length(target_info.sharedclibprefix));
-        { remove extension if any }
-        if Copy(s,length(s)-length(target_info.sharedclibext)+1,length(target_info.sharedclibext))=target_info.sharedclibext then
-          Delete(s,length(s)-length(target_info.sharedclibext)+1,length(target_info.sharedclibext)+1);
-        { ready to be added }
-        SharedLibFiles.Concat(S);
+      { remove prefix 'lib' only if no extension}
+      if (Copy(s,1,length(target_info.sharedclibprefix))=target_info.sharedclibprefix)
+        and (system.pos(target_info.sharedclibext,s) = 0) then
+         Delete(s,1,length(target_info.sharedclibprefix));   
+    
+       SharedLibFiles.Concat(S);
       end;
 
-
     Procedure TLinker.AddFramework(S:TCmdStr);
       begin
         if s='' then
Index: compiler/systems/t_linux.pas
===================================================================
--- compiler/systems/t_linux.pas	(révision 44618)
+++ compiler/systems/t_linux.pas	(copie de travail)
@@ -606,7 +606,7 @@
                   begin
                     i:=Pos(target_info.sharedlibext,S);
                     if i>0 then
-                     Delete(S,i,255);
+                     Insert(':',s,1);   // needed for the linker
                     Add('-l'+s);
                     libraryadded:=true;
                   end
so_n_fix.diff (2,808 bytes)   

Sven Barth

2020-04-07 11:44

manager   ~0121998

> Marco is not working on the compiler, so it's unlikely that he'll commit a patch for it.

Correction: The target specific linking *is* something that Marco does work on in the compiler.

> And I agree this change is a BIG change for Unix developers.
> Maybe the biggest change since the first release of fpc.

You're really overestimating this. Bigger changes are support for the POSIX Exception Handling ABI as well as ELF Thread Local Storage support. This? This is nothing compared to that.

> OK, patch added.

Thanks. Though as I said I'm reluctant to add this. It needs to be carefully evaluated what the correct approach is.

fredvs

2020-04-07 12:09

reporter   ~0121999

Last edited: 2020-04-07 13:02

View 8 revisions

> You're really overestimating this.

I was talking about the result, not the code changed.
With those 5 lines of code, Linux users may use and link libraries with so number.

That is a BIG change.
[EDIT]
Of course you always may use a symlink without so number that point to a library with so number.
But this is tricky and oblige people to create a symlink and so to have root access.

> It needs to be carefully evaluated what the correct approach is.

Of course.
[EDIT] I did test with ld.gold linker, no problems, it works too.
Also tested on FreeBSD (t_bsd.pas need same patch), no problems using ld or ld.gold.

> Correction: The target specific linking *is* something that Marco does work on in the compiler.

I know Marco better than my pocket, you will see, one day we will become best friends.

Fre;D

fredvs

2020-04-07 13:11

reporter   ~0122001

Last edited: 2020-04-07 15:20

View 4 revisions

> You're really overestimating this. Bigger changes are support for the POSIX Exception Handling ABI
> as well as ELF Thread Local Storage support. This? This is nothing compared to that.

Note that the patch is only for Linux system.
It will not make problems of compatibility with other systems.

But if you are happy with the patch for Linux, maybe all others systems that use also ld will begin to cry to have it too.
So the same patch than for t_linux.pas (1 line to change) could be applied to all others t_xxxx.pas using ld.
[EDIT]
Of course, if you want, I will add the patch for all the other the systems you want, with pleasure.

But that is a other story.

;-)

Sven Barth

2020-04-08 11:47

manager   ~0122023

> I was talking about the result, not the code changed.

I was as well.

> Of course you always may use a symlink without so number that point to a library with so number.
> But this is tricky and oblige people to create a symlink and so to have root access.

It is however how things work on *nix systems. Linking against a specific version instead of the generic dev symlink is the exception, not the rule.

fredvs

2020-04-08 12:21

reporter   ~0122026

Last edited: 2020-04-08 14:12

View 5 revisions

>It is however how things work on *nix systems.

Ok, I will not restart the same discussion we had some years ago in fpc mailing list, when it finished insulting me and I banned myself from fpc mailing list for that.

NO, NO and NO linking the dev-symlink is not the right way, like explained in all dev-packages, dev-package is fo C developers, working with the develop library.

OK, I understand, you dont want to take care about users, only important for you is your team.

Fre;D

fredvs

2020-04-08 12:34

reporter   ~0122028

Last edited: 2020-04-08 14:31

View 7 revisions

And how do you do if the library does not provide a dev-package and if the library has a so number?
Oblige people to create a symlink without so number, this with root-right?

Do you know that the majority of Linux libraries do not provide dev packages?
Only few, and the goal is helping C developers who need the header of the develop library,
 to not oblige them to use source from svn or github, etc...

Did you note too that in a Linux or FreeBSD distro, the majority of libraries does use so numbers without providing the symlink "nude"?

https://stackoverflow.com/questions/19032398/what-does-the-dev-dbg-and-utils-mean

[EDIT]
Now if you really want to do like your C friends, fpc should provide to each distro a "pas-dev" package for each library, with for example the conversion of the C header into a dynamic loading Pascal unit, some infos, ... why not.

But using the dev package that is for C developers has no sense.

fredvs

2020-04-08 13:50

reporter   ~0122032

>> And I agree this change is a BIG change for Unix developers.
>> Maybe the biggest change since the first release of fpc.

> You're really overestimating this.

Really?

fredvs

2020-04-08 14:56

reporter   ~0122033

Last edited: 2020-04-08 17:53

View 4 revisions

OK, I see that about the dev package I have to give it up, I am not Galileo.

So if you prefer to oblige people to install dev package, no problem.
The patch let you free to do:

Xlib : "X11" or Xlib : "libX11", like it is now in fpc package and it will still link with libX11.so, like it always did.

But is it a so big crime to let people do:

Xlib : "libX11.so.6" to be able to link directly with libX11.so.6

?

I am not Galileo but it smells like im in the Inquisition.

fredvs

2020-04-08 19:08

reporter   ~0122038

Nobody to stop my indictment?

OK, I continue.

Even Kylix did it!

https://books.google.es/books?id=mpvSnBZTsOgC&pg=PA410&lpg=PA410&dq=kylix+external+library+call&source=bl&ots=qwJA3_7HHW&sig=ACfU3U2qZt3V4-Eef5XjmjeSC4nxyyBQMA&hl=fr&sa=X&ved=2ahUKEwjKlf-kpdnoAhUoxIUKHeq0DJIQ6AEwAHoECAsQLA#v=onepage&q=kylix%20external%20library%20call&f=false

Do a google search: "kylix external library call"

Click on "Kylix Developer's Guide"

Resume:

Page 410: Calling Library Routines from a Kylix program

const
   libsimple='libsimple.so';

function GetNine: Integer; external libsimple name 'GetNine'

And take a look at page that follows that uses library with so number.

Huh, Kylix is part of Delphi, it should be the best argument.

And the last, I am tired.

Fre;D

Issue History

Date Modified Username Field Change
2017-09-02 10:52 Martin Schreiber New Issue
2017-09-03 21:28 Marco van de Voort Note Added: 0102622
2017-09-04 07:26 Martin Schreiber Note Added: 0102625
2017-10-13 13:01 Marco van de Voort Note Added: 0103404
2017-11-16 11:29 Thaddy de Koning Note Added: 0104131
2018-01-12 10:20 Martin Schreiber Note Added: 0105688
2018-01-12 13:10 Martin Schreiber Note Added: 0105692
2018-01-12 13:10 Thaddy de Koning Note Added: 0105693
2018-01-12 19:35 Marco van de Voort Note Added: 0105719
2018-01-13 06:40 Martin Schreiber Note Added: 0105725
2018-02-16 21:06 Marco van de Voort Note Added: 0106407
2018-02-20 18:09 fredvs Note Added: 0106489
2018-02-21 18:14 fredvs Note Added: 0106518
2018-02-21 19:43 fredvs Note Added: 0106520
2018-03-04 18:49 Florian Note Added: 0106862
2018-03-04 18:52 Marco van de Voort Note Edited: 0106407 View Revisions
2018-03-04 18:53 Marco van de Voort Note Added: 0106864
2018-03-05 00:05 Martok Note Added: 0106871
2018-03-05 01:15 Martok Note Edited: 0106871 View Revisions
2020-04-04 17:58 fredvs File Added: t_linux.pas.zip
2020-04-04 17:58 fredvs File Added: link.pas.zip
2020-04-04 17:58 fredvs Note Added: 0121905
2020-04-04 18:05 fredvs Note Edited: 0121905 View Revisions
2020-04-04 18:28 fredvs Note Edited: 0121905 View Revisions
2020-04-05 13:22 fredvs File Added: link.pas-2.zip
2020-04-05 13:22 fredvs File Added: t_linux.pas-2.zip
2020-04-05 13:22 fredvs Note Added: 0121937
2020-04-05 13:23 fredvs Note Edited: 0121937 View Revisions
2020-04-06 13:17 fredvs Note Added: 0121961
2020-04-06 13:49 fredvs Note Edited: 0121961 View Revisions
2020-04-06 14:19 Bi0T1N Note Added: 0121963
2020-04-06 14:35 Marco van de Voort Note Added: 0121965
2020-04-06 14:40 fredvs Note Added: 0121966
2020-04-06 14:44 fredvs Note Edited: 0121966 View Revisions
2020-04-06 14:46 fredvs Note Added: 0121967
2020-04-06 15:00 fredvs Note Edited: 0121966 View Revisions
2020-04-06 16:49 fredvs Note Edited: 0121966 View Revisions
2020-04-06 17:49 Sven Barth Note Added: 0121977
2020-04-06 17:50 Sven Barth Note Edited: 0121977 View Revisions
2020-04-06 18:11 fredvs Note Added: 0121979
2020-04-06 18:26 fredvs Note Added: 0121980
2020-04-06 19:43 fredvs Note Added: 0121983
2020-04-06 22:03 fredvs File Added: so_n_fix.diff
2020-04-06 22:03 fredvs Note Added: 0121986
2020-04-07 11:44 Sven Barth Note Added: 0121998
2020-04-07 12:09 fredvs Note Added: 0121999
2020-04-07 12:16 fredvs Note Edited: 0121999 View Revisions
2020-04-07 12:44 fredvs Note Edited: 0121999 View Revisions
2020-04-07 12:44 fredvs Note Edited: 0121999 View Revisions
2020-04-07 12:55 fredvs Note Edited: 0121999 View Revisions
2020-04-07 12:55 fredvs Note Edited: 0121999 View Revisions
2020-04-07 12:56 fredvs Note Edited: 0121999 View Revisions
2020-04-07 13:02 fredvs Note Edited: 0121999 View Revisions
2020-04-07 13:11 fredvs Note Added: 0122001
2020-04-07 13:12 fredvs Note Edited: 0122001 View Revisions
2020-04-07 13:32 fredvs Note Edited: 0122001 View Revisions
2020-04-07 15:20 fredvs Note Edited: 0122001 View Revisions
2020-04-08 11:47 Sven Barth Note Added: 0122023
2020-04-08 12:21 fredvs Note Added: 0122026
2020-04-08 12:23 fredvs Note Edited: 0122026 View Revisions
2020-04-08 12:34 fredvs Note Added: 0122028
2020-04-08 12:35 fredvs Note Edited: 0122026 View Revisions
2020-04-08 12:36 fredvs Note Edited: 0122026 View Revisions
2020-04-08 12:59 fredvs Note Edited: 0122028 View Revisions
2020-04-08 13:00 fredvs Note Edited: 0122028 View Revisions
2020-04-08 13:04 fredvs Note Edited: 0122028 View Revisions
2020-04-08 13:44 fredvs Note Edited: 0122028 View Revisions
2020-04-08 13:50 fredvs Note Added: 0122032
2020-04-08 14:12 fredvs Note Edited: 0122026 View Revisions
2020-04-08 14:30 fredvs Note Edited: 0122028 View Revisions
2020-04-08 14:31 fredvs Note Edited: 0122028 View Revisions
2020-04-08 14:56 fredvs Note Added: 0122033
2020-04-08 14:58 fredvs Note Edited: 0122033 View Revisions
2020-04-08 17:37 fredvs Note Edited: 0122033 View Revisions
2020-04-08 17:53 fredvs Note Edited: 0122033 View Revisions
2020-04-08 19:08 fredvs Note Added: 0122038