Hi listers,

I have installed FPC 2.4.4 using the following package: http://mirrors.iwi.me/lazarus/snapshots/fpc-2.4.4-1.i386.deb.tar Having unpacked it in a folder, I did:
sudo dpkg -i *.deb
The instalation was seemingly successful since I could compile some sources. However, compiling the attached example, I got an error: fpc macuco.pas > output
The output file has received the following content: Free Pascal Compiler version 2.4.4-1 [2011/05/24] for i386 Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Linux for i386
Compiling macuco.pas
Compiling macbase.pas
Linking macuco
macuco.pas(14,1) Error: Error while linking
macuco.pas(14,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: /usr/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled)

The executable was not generated. In its place, I found "link.res". The compilation was successful, but for a unknown reason, the linkage was not completed. I don't understand what the statements in link.res means indeed.
In spite of the output redirection, a statement was writen in console in stead of the output file.

Cannot find -lsqlite3

I tried a reinstalation:

sudo apt-get purge fp-compiler
sudo apt-get autoremove
cd /home/luciano/fpc-2.4.4-1.i386/
sudo dpkg -I *deb

After it, the compiler shows the same behaviour and the described error continues. The compiler seems to be working correctly when I don't use "uses db, sqlite3ds'.
Does someone know what it is wrong?
I use FPC 2.4.4 without Lazarus and Ubuntu 10.10.

Luciano

Luciano de Souza wrote

The executable was not generated. In its place, I found "link.res". The compilation was successful, but for a unknown reason, the linkage was not completed. I don't understand what the statements in link.res means indeed. In spite of the output redirection, a statement was writen in console in stead of the output file. Cannot find -lsqlite3

sqlite3 is not part of FPC. You probably have to install the sqlite3-dev package or something like that. Arguably, that should be a dependency of the fpc .deb package that installs support for interfacing with sqlite3.

Jonas

Everything is solved with a magic: "sudo apt-get install libsqlite3-dev".

I tested the same example and the executable was generated.

Thank you. Your reply helped me a lot!

I advise against this.

This would add a whole list of unwanted dependencies to e.g. lazarus since it installs support for many databases by default. It loads the needed libraries on-demand; if someone needs it, he/she can install the needed libraries with the package-manager.

Michael.

Afaik it is already the case for most FPC .debs as shipped with Debian (there have been plenty of discussions about that in the past). It's how Debian tries to prevent problems like the one in this thread. Doing it in most cases but not in all is however worse than either doing it always or never doing it.

Jonas

Michael Van Canneyt wrote

This would add a whole list of unwanted dependencies to e.g. lazarus since it installs support for many databases by default. It loads the needed libraries on-demand; if someone needs it, he/she can install the needed libraries with the package-manager.

Are you sure? I think it works differently. Lazarus bigide includes design-time support only for those datasets without any external dependencies. Other datasets have to be installed by the user, or used without design support (like I do). And when they are installed the IDE gains a static dependency on them from what I remember, so, for example, you need to copy DLLs to the Lazarus directory if you install such packages. I think that releases use bigide (not sure since I'm always in trunk, however)

But indeed it would cause problems for people installing the debs for sure, because there is a truck load of deb files, so selecting which ones you want/need is a long and boring task, so I usually just try to install *.deb, which would unwantedly install a truckload of databases now =D

Another big problem is the more dependencies you add, the more distribution specific the packages get, so if packages are named differently in Ubuntu vs Debian vs other deb-based you get a package which does not install everywhere.

The RPM has the inverse problem. It is 1 with everything, so if theorically you added dependencies there too you would have immense dependencies for FPC, which would surely make the package impossible to install in most systems. Actually it is already impossible to install FPC RPMs in PCLinuxOS and other systems because of the text-mode IDE dependencies.

In our previous episode, Jonas Maebe said:

It is a problem if in FPC's case the common use is the "other" one (via fcl-db that uses the dynloaded variants)

If this is really needed, we probably need to make the package granularity finer. (-dyn and static in separate packages, so that the static one alone gets the dependency. Lazarus then only depends on the dyn packages).

However this is a challenge for fpmake probably, packages that share source ?

In our previous episode, Felipe Monteiro de Carvalho said:

Are you sure? I think it works differently. Lazarus bigide includes design-time support only for those datasets without any external dependencies.

If the database packages get dependancies to the corresponding c-clientlibs, then fcl-db will get dependencies on all these C db client libs. Even if you only use tbufdataset.

Marco van de Voort wrote

If the database packages get dependancies to the corresponding c-clientlibs, then fcl-db will get dependencies on all these C db client libs. Even if you only use tbufdataset.

Aha, in that case this proposal is really a no go.

No.
sqldblaz which installs support for sql-db is a single database package, with no external dependencies. It loads the needed libraries on-demand.

As you already noted from Marco's reply, this would pull in a lot of C libs.

Michael.

That would be a regular nightmare, because there are many packages that depend on fcl-db, and this would split all these packages in 2 variants.

There is a good reason that apache, php, ODBC and many other large programs/ libraries introduced dynamically loadable packages. It saves you from having to recompile everything for your particular system, and thus makes maintenance and installation simpler.

So if anything, IMHO we should make all packages that link in external C libs "dynamically loaded".

Michael.

Jonas Maebe wrote

sqlite3 is not part of FPC. You probably have to install the sqlite3-dev package or something like that. Arguably, that should be a dependency of the fpc .deb package that installs support for interfacing with sqlite3.

I agree with Michael here... Adding such a dependency would be bad (sometimes Debian's package dependencies policy can be damn annoying). Lets take a look.... SqlDB works with MySQL, SQLite, Firebird, PostgreSQL etc... So in that case, fpc.deb should have package dependencies to all those RDBMS too. :-(

In our previous episode, Michael Van Canneyt said:

This only shifts the problem from having to say "install the static version of the C lib" to having to say "install the relevant FPC/lazarus db package".

With one benefit (you can provide custom errormessages), and one major disadvantage (a lot of release engineering and versioning)

I don't understand this remark ? What static version of the C lib ?

The -dev packages install a symlink (.so) and header files, not a static lib.

It's been years since I've seen a static lib installed, and as a rule, I install lots of -dev packages.

As for additional work: we need to do the work anyway. If a lib changes versions, we need to adapt our units anyway, dynamic or not.

Michael.