<Continuation of discussion from "Cross-building on from Linux/x86-64 to Linux/i386 (was: Win64 release of FPC 2.6.2 missing)">

It is the other way round. My OS is 32 bit Ubuntu and one of the targets is Linux/x86-64, so I assume you mean the 64 bit paths and not the 32 bit ones.

I tried setting CROSSOPT (CROSSOPT="-XR/usr/lib64
-Fl/usr/lib/gcc/i686-linux-gnu/4.7/64"), but the line that fails ("/usr/bin/ld: cannot find -lgcc") is:
/home/user1/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppc fpmake.pp -n -Fu/home/user1/Programs/fpc/fpsrc/exported/2.7.1/packages/fpmkunit/units_bs/i386-linux -Fu/home/user1/Programs/fpc/fpsrc/exported/2.7.1/rtl/units/i386-linux -Xd -Xt -gl

None of the paths from CROSSOPT are mentioned in the above line.

In one experiment, I even put -Fl 64 bit paths in OPT. The above line compiled, but a [smart] error 216 occurred right after. I have no idea what that is.

As Florian mentioned, the compiling the entire tree now depends on certain C libraries, and hence you have to tell the build process where to find these (and the associated startup code files) if they are not in the standard directories.

This is obvious, and libgcc, libc, crti.o came from a regular repository package install. In other words, they are supposed to be in the standard directories.

libc.a and crti.o are in: /usr/lib/i386-linux-gnu and /usr/lib64 while libgcc.a is in: /usr/lib/gcc/i686-linux-gnu/4.7.3 and /usr/lib/gcc/i686-linux-gnu/4.7.3/64

Moreover, make fpc_baseinfo... show GCCLIBDIR and OTHERLIBDIR to be empty. I am not sure if this is relevant or not.

I even setup a new Ubuntu 13.04 VM, and installed binutils from the repo (instead of building them myself) to no avail.

> http://bugs.freepascal.org/view.php?id=24372 And does the linker not interpret that parameter correctly? Even if it doesn't, that does not appear to be a problem specific to cross building.

I tried to replace the include directive with the actual paths. No improvement. Either it is not needed by the cross building process or the new cross building (fpmake?) neglects to use it. I am inclined to believe the latter as fpcmake.ini contains:
OTHERLIBDIR:=$(shell cat /etc/ld.so.conf.d/* | grep -v "^\#" | awk '{ ORS=" "; print $1 }')
which should in theory list the ld paths, but produces (with FPC 2.6.3) instead -Flinclude and -Fl/etc/ld.so.conf.d/*.conf switches.

As a workaround for FPC 2.6.3, I passed the 64 bit paths in the LIBDIR parameter of make. Unfortunately, this workaround does not work with FPC 2.7.1.

PS: when asking questions about a different topic, at change the subject (and preferably start a new thread

Definitely, though my post was inspired by your post regarding the difficulty of building of cross compilers.

Thanks,
Stephano

That is by design. fpmake runs on the host, not on the target. /home/user1/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppc is a native compiler (so i386->i386 in your case). Options specific to compiling fpmake can be passed using FPMAKEOPT, so add FPMAKEOPT="-Fl/path/to/32bit/libgcc/directory" to your build invocation. I also don't know where the "-Xd" comes from in the above compiler invocation. If you added that yourself, remove it again. At most, you can add it to CROSSOPT, but never to OPT (since it tells FPC to not search the standard library paths and OPT is used for "native" compiles, so why would you want the compiler not to search the standard library paths when doing native compiles?). And you don't need it at all, not even in CROSSOPT, if you use -XR in CROSSOPT (or rather: you mustn't use it at all if you use -XR, since that will then prevent the compiler from searching the standard library paths under the alternative root).

This is obvious, and libgcc, libc, crti.o came from a regular repository package install. In other words, they are supposed to be in the standard directories.

Do "standard cross-compilation library directories" exist on Linux in general? (as in "distribution-independent")

libc.a and crti.o are in: /usr/lib/i386-linux-gnu and /usr/lib64 while libgcc.a is in: /usr/lib/gcc/i686-linux-gnu/4.7.3 and /usr/lib/gcc/i686-linux-gnu/4.7.3/64 Moreover, make fpc_baseinfo... show GCCLIBDIR and OTHERLIBDIR to be empty. I am not sure if this is relevant or not.

Neither variable is set or used by the Makefile by default. I guess them being shown in "make info" is a relic from the past, and those lines should probably be removed.

>> http://bugs.freepascal.org/view.php?id=24372 > And does the linker not interpret that parameter correctly? Even if it doesn't, that does not appear to be a problem specific to cross building. I tried to replace the include directive with the actual paths. No improvement. Either it is not needed by the cross building process

It is most likely completely unrelated to what you are experiencing here.

> PS: when asking questions about a different topic, at change the subject (and preferably start a new thread Definitely, though my post was inspired by your post regarding the difficulty of building of cross compilers.

It was not about building cross-compilers. It was about compiling regular programs using using cross-compilers that we have already compiled and configured in advance and offer for download on our website.

Jonas

Shouldn't it be FPCMAKEOPT for compiling fpmake.pp? FPMAKEOPT seems to pass options to fpmake itself.

Cross compiling for Linux/x86_64 with
FPCMAKEOPT="-Fl/usr/lib/gcc/i686-linux-gnu/4.7" went past the previous error point, but yet yielded another error:

./fpmake compile --localunitdir=.. --os=linux --cpu=x86_64 -o -Px86_64 -o -XPx86_64-linux- -o -Xr -o -Ur -o -Xs -o -O2 -o -n -o -Fu/home/user1/Programs/fpc/fpsrc/exported/2.7.1/rtl/units/x86_64-linux -o -Cg -o -Xt -o -dx86_64 -o -dRELEASE
--compiler=/home/user1/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppcrossx64 -bu -sp -o -XX -o -CX
make[2]: *** [smart] Error 216
make[2]: Leaving directory
`/home/user1/Programs/fpc/fpsrc/exported/2.7.1/packages' make[1]: *** [packages_smart] Error 2
make[1]: Leaving directory `/home/user1/Programs/fpc/fpsrc/exported/2.7.1' make: *** [build-stamp.x86_64-linux] Error 2

What could be causing this error?

Note: I used the following (part of a script) to build the cross compiler (the 1st one triggers the errors):
${MAKE} clean all OS_TARGET=${OS} CPU_TARGET=${CPU} OPT="-Xt" FPCMAKEOPT="-Fl/usr/lib/gcc/i686-linux-gnu/4.7"
${MAKE} crossinstall INSTALL_PREFIX=${DESTDIR} OS_TARGET=${OS} CPU_TARGET=${CPU} OPT="-Xt" CROSSOPT="-Xd"
FPCMAKEOPT="-Fl/usr/lib/gcc/i686-linux-gnu/4.7"

I also don't know where the "-Xd" comes from in the above compiler invocation. If you added that yourself, remove it again.

I inherited it from the buildcrosssnapshot script found in fpcbuild-2.6.2.zip, and never even thought about its effect.

At most, you can add it to CROSSOPT, but never to OPT (since it tells FPC to not search the standard library paths and OPT is used for "native" compiles, so why would you want the compiler not to search the standard library paths when doing native compiles?). And you don't need it at all, not even in CROSSOPT, if you use -XR in CROSSOPT (or rather: you mustn't use it at all if you use -XR, since that will then prevent the compiler from searching the standard library paths under the alternative root).

I suppose the multiarch root path for Linux/x86_64 should be /usr/lib/i686-linux-gnu, but this directory does not exist even on Ubuntu 13.04. Any ideas?

>>> http://bugs.freepascal.org/view.php?id=24372 >> And does the linker not interpret that parameter correctly? Even if it doesn't, that does not appear to be a problem specific to cross building. > I tried to replace the include directive with the actual paths. No improvement. Either it is not needed by the cross building process It is most likely completely unrelated to what you are experiencing here.

Once I am able to rebuild the cross compilers, I'll restore the include directive and hence find out for sure.

Note: Are crossall, FPMAKEOPT, FPCMAKEOPT, etc.. mentioned in any fpc manual? I could not find them.

Thanks for your support!

Stephano

patspiper wrote

On 07/05/13 21:01, Jonas Maebe wrote: > That is by design. fpmake runs on the host, not on the target. /home/user1/Programs/fpc/fpsrc/exported/2.7.1/compiler/ppc is a native compiler (so i386->i386 in your case). Options specific to compiling fpmake can be passed using FPMAKEOPT, so add FPMAKEOPT="-Fl/path/to/32bit/libgcc/directory" to your build invocation. Shouldn't it be FPCMAKEOPT for compiling fpmake.pp? FPMAKEOPT seems to pass options to fpmake itself.

Yes, sorry.

Error 216 is a segmentation fault. It looks like a bug in fpmake. I've never seen this before. I don't know what causes it.

Note: I used the following (part of a script) to build the cross compiler (the 1st one triggers the errors): ${MAKE} clean all OS_TARGET=${OS} CPU_TARGET=${CPU} OPT="-Xt" FPCMAKEOPT="-Fl/usr/lib/gcc/i686-linux-gnu/4.7" ${MAKE} crossinstall INSTALL_PREFIX=${DESTDIR} OS_TARGET=${OS} CPU_TARGET=${CPU} OPT="-Xt" CROSSOPT="-Xd" FPCMAKEOPT="-Fl/usr/lib/gcc/i686-linux-gnu/4.7"

I would get rid of the -Xt and use a proper -XR parameter instead of -Xd.

> I also don't know where the "-Xd" comes from in the above compiler invocation. If you added that yourself, remove it again. I inherited it from the buildcrosssnapshot script found in fpcbuild-2.6.2.zip, and never even thought about its effect.

That script probably hasn't been used for ages. It's probably best to remove it in order to prevent confusion like you are encountering.

> At most, you can add it to CROSSOPT, but never to OPT (since it tells FPC to not search the standard library paths and OPT is used for "native" compiles, so why would you want the compiler not to search the standard library paths when doing native compiles?). And you don't need it at all, not even in CROSSOPT, if you use -XR in CROSSOPT (or rather: you mustn't use it at all if you use -XR, since that will then prevent the compiler from searching the standard library paths under the alternative root). I suppose the multiarch root path for Linux/x86_64 should be /usr/lib/i686-linux-gnu, but this directory does not exist even on Ubuntu 13.04. Any ideas?

Other than the fact that there are barely any standards on Linux? No.

Note: Are crossall, FPMAKEOPT, FPCMAKEOPT, etc.. mentioned in any fpc manual? I could not find them.

They might be part of Marco's buildfaq, but I don't know whether it has been updated already for fpmake.

Jonas

Removing -Xt eliminated error 216 and the cross compiler was successfully built for Linux/x86_64, Win/i386, Win/x86_64, and arm-WinCE! At least the cause of the bug is known now.

arm-linux failed, but for some other reason (editors.pas(3798) Error: Error while assembling exitcode 1).

Moreover, FPCMAKEOPT was no more needed once -Xt was removed!

I will test tomorrow if the win/i386 cross compiler actually works :) , and reinstate the include directive in the etc/ld.so.conf file.

>> I also don't know where the "-Xd" comes from in the above compiler invocation. If you added that yourself, remove it again. > I inherited it from the buildcrosssnapshot script found in fpcbuild-2.6.2.zip, and never even thought about its effect. That script probably hasn't been used for ages. It's probably best to remove it in order to prevent confusion like you are encountering.

+1

>> At most, you can add it to CROSSOPT, but never to OPT (since it tells FPC to not search the standard library paths and OPT is used for "native" compiles, so why would you want the compiler not to search the standard library paths when doing native compiles?). And you don't need it at all, not even in CROSSOPT, if you use -XR in CROSSOPT (or rather: you mustn't use it at all if you use -XR, since that will then prevent the compiler from searching the standard library paths under the alternative root). > I suppose the multiarch root path for Linux/x86_64 should be /usr/lib/i686-linux-gnu, but this directory does not exist even on Ubuntu 13.04. Any ideas? Other than the fact that there are barely any standards on Linux? No.

At least this is what https://wiki.ubuntu.com/MultiarchSpec says. But I cannot find this directory on my system.

> Note: Are crossall, FPMAKEOPT, FPCMAKEOPT, etc.. mentioned in any fpc manual? I could not find them. They might be part of Marco's buildfaq, but I don't know whether it has been updated already for fpmake.

I had gone through it scrounging for info. fpmake is almost undocumented (except for a wiki page).

Stephano

In our previous episode, Jonas Maebe said:

Please don't, since that just makes it hard to add anything. Amend it, and if you don't have the time, add a warning if you are afraid that it will cause confusion, but don't delete files.

> Note: Are crossall, FPMAKEOPT, FPCMAKEOPT, etc.. mentioned in any fpc manual? I could not find them. They might be part of Marco's buildfaq, but I don't know whether it has been updated already for fpmake.

No. CROSSOPT isn't even. It needs quite some updating, I hope to find time for it somewhere this summer.

I don't understand what you mean by this. How does it make it "hard to add anything"? Add what to what?

Amend it, and if you don't have the time, add a warning if you are afraid that it will cause confusion, but don't delete files.

It's too late, I already deleted it. Furthermore, it dates back to the CVS days (it hasn't been updated a single time since we switched to svn) and probably hasn't worked correctly in 10 years or so (if it ever worked really correctly, given that adding -Xd to OPT never never was correct). You can always get it back from the history if you want to.

Jonas

In our previous episode, Jonas Maebe said:

To the project. This is the first time that sb makes a comment about it, and before I can even look into it, it is deleted? What kind of procedure is that?

Yes it was old, and had defects. But that is not a reason to directly delete it with only a few hours of advance warning on a working day.

svn) and probably hasn't worked correctly in 10 years or so (if it ever worked really correctly, given that adding -Xd to OPT never never was correct).

It was the best that could be done then. And it did work, because back then, with the exception of darwin, nothing run on host linked to libc, thus not needing those paths. That has only changed very recently.

You can always get it back from the history if you want

I'll restore it, and see if I can make some updates tonight.

How does deleting decade-old cruft that confuses people make it hard to add new things to the project? It's not like I or anyone else is constantly looking for files that haven't been touched in the past year and deleting them.

This is the first time that sb makes a comment about it,

Probably because no one else realised it still exists or tried to use it.

and before I can even look into it, it is deleted? What kind of procedure is that?

I didn't think much of it because of the aforementioned reasons. It honestly did not occur to me that somebody would still care about the existence of that particular script, given that it explicitly contained references to paths with "cvs" in them and hence hasn't even been used for a long time by anyone.

The best that could have been done was to add -Xd to CROSSOPT, not to OPT.

And it did work, because back then, with the exception of darwin, nothing run on host linked to libc, thus not needing those paths. That has only changed very recently.

You're right. But in that case I don't understand why -Xt was also present, given that this option only applies to C libraries as well.

Jonas

In our previous episode, Jonas Maebe said:

IIRC that didn't exist outside cycle then.

Neither do I. It is not an option that I regularly use. Maybe it was a workaround for the problems where later -Xr (rlink-path) was added for. IOW cross-shared linking wasn't so easy then.

Anyway, I'll update and play with it in the coming times. I had already planned to spend some time on the buildfaq, and this is good training.

I have a flexible script based on that which I am currently tweaking to make it work again. Once I am more or less satisfied with it, and if you are interested, I can send it to you. I burned my fingers with cross compiler building until Jonas saved my day. Maybe I can save others the same grief.

Stephano