[MSEide-MSEgui-talk] Multi-arch problem...

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Hello Martin.

I try to make my new Linux (Manjaro xfce) 64 bit multi arch work.

OK, compiling 32 bit MSE application with fpc32 is OK on the 64 bit OS.

But, while running (with gdb) the 32 bit app on the 64 bit system, there is
that error + crash:

(gdb) run
Starting program: /home/fred/strumpract_bin/StrumPract_linux32/strumpract
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
An unhandled exception occurred at $0815C2B4 :
EReadError : Error reading configfo.windowopacity: Unknown property:
"windowopacity"
  $0815C2B4  TREADER__READPROPERTY,  line 6571 of
/home/fred/msegui/lib/common/fpccompatibility/mclasses.pas
  $0815B8FB  TREADER__READDATA,  line 6276 of
/home/fred/msegui/lib/common/fpccompatibility/mclasses.pas
  $0815566B  TCOMPONENT__READSTATE,  line 1718 of
/home/fred/msegui/lib/common/fpccompatibility/mclasses.pas
  $080CCD70  LOADMODULE,  line 2360 of
/home/fred/msegui/lib/common/kernel/mseclasses.pas
  $080CD354  DOLOAD,  line 3059 of
/home/fred/msegui/lib/common/kernel/mseclasses.pas
  $080CD161  INITMSECOMPONENT,  line 3083 of
/home/fred/msegui/lib/common/kernel/mseclasses.pas
  $080CD3C0  LOADMSEMODULE,  line 3201 of
/home/fred/msegui/lib/common/kernel/mseclasses.pas
  $080D3DA2  TMSEFORM__CREATE,  line 2298 of
/home/fred/msegui/lib/common/widgets/mseforms.pas
  $080D19FB  TCUSTOMMSEFORM__CREATE,  line 1048 of
/home/fred/msegui/lib/common/widgets/mseforms.pas
  $080CCC29  CREATEMODULE,  line 2312 of
/home/fred/msegui/lib/common/kernel/mseclasses.pas

Not very important because I did try the app on a real-only 32 bit sytem and
it is ok.

But I do not understand why there is a error on multi-arch because of
Unknown property: "windowopacity" on the 32 bit app but not with the 64 bit
app.

PS: It s not important but maybe you know why there is that problem (if you
do not know, sorry for the noise).

Fre;D




--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Aaargh.

It seems to be a Manjaro+MSE problem.

Compiling a 64 bit app is ok but running it:

An unhandled exception occurred at $000000000060B7BA :
EReadError : Error reading configfo.windowopacity: Unknown property:
"windowopacity"
  $000000000060B7BA line 6571 of
../../msegui/lib/common/fpccompatibility/mclasses.pas

?

Strange because the same application (compiled with Mint 64) works like
charm on Manjaro 64.

;-(



--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Re-hello.

OK, I get a work-around.

in /msegui/lib/common/fpccompatibility/mclasses.pas

At line 6573 + 6574, comment this:

 //   raise EReadError.CreateFmt(SPropertyException,
 //     [Name, DotSep, Path, e.Message]);

Without those lines, the app 64 bit run OK (no crash).

But for the app 32 bit, now the app crash with this:

An unhandled exception occurred at $F76DD613 :
EAccessViolation : Access violation
  $F76DD613
Xft: locking error Attempt to close locked file

....

Fre;D




--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

mse
Administrator
In reply to this post by fredvs
On Friday 20 July 2018 01:34:24 fredvs wrote:

> Aaargh.
>
> It seems to be a Manjaro+MSE problem.
>
> Compiling a 64 bit app is ok but running it:
>
> An unhandled exception occurred at $000000000060B7BA :
> EReadError : Error reading configfo.windowopacity: Unknown property:
> "windowopacity"
>   $000000000060B7BA line 6571 of
> ../../msegui/lib/common/fpccompatibility/mclasses.pas
>
tcustommseform.windowopacity has been introduced recently. I assume you try to
load a form produced by current MSEide with an old MSEgui mseforms unit.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
> tcustommseform.windowopacity has been introduced recently. I assume you try
to
> load a form produced by current MSEide with an old MSEgui mseforms unit.

Yes, it must be the problem.
The mseforms unit was created with a OS that use windowopacity.
And it seems that Manjaro xfce does not use windowopacity.

Hum, dont you think that a crash is a litlle too big sanction for the OS
because not using windowopacity ?
(IMHO raise a exception is hard).

By the way, there is still a bug in fpc for multi-arch compatibility.

When using fpc in some multi-arch OS (64 and 32 bit), the compilation of fpc
fail in 32 bit.
This is caused by the wrong search path used for the linker.

...
Linking strumpract
/usr/bin/ld : avertissement : link.res contient des sections de sortie;
avez-vous oublié -T?
/usr/bin/ld : escamotage incompatible /lib/crti.o lors de la recherche de
/lib/crti.o
/usr/bin/ld : ne peut trouver /lib/crti.o
strumpract.pas(137,1) Error: Error while linking
strumpract.pas(137,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
...

For example, in a Arch-Manjaro OS,

64 bit libraries are in /lib or /usr/lib or /usr/lib64
32 bit libraries are in /usr/lib32

If you use the -sh parameter at compilation (to have a script for the
linker), in link.res:
...

INPUT(
/usr/lib32/crtend.o
/lib/crtn.o
)

----> Should be:

INPUT(
/usr/lib32/crtend.o
/usr/lib32/crtn.o
)

If changing this in link.res, the compilation is ok.

What I do as fast workaround when I need to cross-compil into 32 bit is this
before compilation:

(the 32 bit is /usr/lib32/crtn.o  and a copy of the 64 bit is
/usr/lib/crtn64.o)

$ sudo cp /usr/lib32/crtn.o /lib/crtn.o

And before compiling 64 bit:

$ sudo cp /usr/lib/crtn64.o /lib/crtn.o

Tricky but works perfectly.

Martin, dont worry, I will not annoy fpc team with that bug ;-)

Fre;D





--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

mse
Administrator
On Friday 20 July 2018 15:22:50 fredvs wrote:

> > tcustommseform.windowopacity has been introduced recently. I assume you
> > try
>
> to
>
> > load a form produced by current MSEide with an old MSEgui mseforms unit.
>
> Yes, it must be the problem.
> The mseforms unit was created with a OS that use windowopacity.
> And it seems that Manjaro xfce does not use windowopacity.
>
> Hum, dont you think that a crash is a litlle too big sanction for the OS
> because not using windowopacity ?
> (IMHO raise a exception is hard).
>
It has nothing to do with the window manager. In the *_mfm.pas file and
probably in the *.mfm file too there is a property value for
tcustomform.windowopacity stored which does not exist in the mseform unit you
use. Please ensure that you use the mseform.pas file from current git master
branch everywhere and ensure that the used mseform.ppu will be recompiled.

> By the way, there is still a bug in fpc for multi-arch compatibility.
>
> When using fpc in some multi-arch OS (64 and 32 bit), the compilation of
> fpc fail in 32 bit.
> This is caused by the wrong search path used for the linker.
>
The compiler parameters must be setup correctly. Important is -n so no
existing fpc.cfg influences the setup.
Have a look how it is done for ARM cross compiling
https://gitlab.com/mseide-msegui/mseuniverse/tree/master/samples/raspberrypi/helloworld
The used cross environment is here (32 bit host):
https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/crossfpc-i386_linux_eabihf_3_0_5.tar.gz/download
or here (64 bit host):
https://sourceforge.net/projects/mseide-msegui/files/fpcrossarm/crossfpc-x86_64_linux_eabihf_3_0_5.tar.gz/download

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
> Please ensure that you use the mseform.pas file from current git master
> branch everywhere and ensure that the used mseform.ppu will be recompiled.

Of course I did use the last msegui from Gitlab and deleted all the .ppu and
.o before compile.
Anyway now it is fixed (and I do not know how to reproduce the error).

> Have a look how it is done for ARM cross compiling.

Many thanks for this, I will study it.

PS: The bug I am talking has nothing to do with cross compiling.
I mean using  fpc 32 bit on a 64 bit multi-arch OS.

It should compile and link a 32 bit executable out of the box.
The wrong path (not /usr/lib/32) only affect ctri.o and ctrn.o, all other
system libraries have correctly /us/lib32 as path.

But maybe it is not fpc the guily but the OS that does not recognize the
correct ELF for ctri.o and ctrn.o
before to give it to the linker.

--> librarysearchpath.FindFile('crti.o',false,s) ---> in t_linux.pas

Fre;D

 





--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

mse
Administrator
On Friday 20 July 2018 22:12:47 fredvs wrote:
>
> PS: The bug I am talking has nothing to do with cross compiling.
> I mean using  fpc 32 bit on a 64 bit multi-arch OS.
>
Add to the FPC commandline
-n       (do not load the default cfg file)
-Xd      (do not use the standard library path)
-Fl<thedirectory of the 32 bit *.o's>
-e<thedirectory of 32 bit linker and assembler>

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
> -Xd      (do not use the standard library path)

link.res without Xd parameter:
 (and of course with correct -e<thedirectory of 32 bit linker and assembler>
and Fl<thedirectory of the 32 bit *.o's>)
(that is what I did) --------->

SEARCH_DIR("/lib/")
SEARCH_DIR("/usr/lib/")
SEARCH_DIR("/usr/lib32/")
SEARCH_DIR("/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/32/")
...
INPUT(
/usr/lib32/crtend.o
/lib/crtn.o
)

----------------------

Now link.res **WITH** Xd parameter:
 (and of course with correct -e<thedirectory of 32 bit linker and assembler>
and Fl<thedirectory of the 32 bit *.o's>)
--------->

SEARCH_DIR("/usr/lib32/")
SEARCH_DIR("/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/32/")
...
INPUT(
/usr/lib32/crtend.o
/usr/lib32/crtn.o
)

------------------------

Conclusion: Yes, Martin, you are the biggest FPC guru that exists.

Many thanks. (And once again, big WoW).


Fre;D







--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Re-hello.

Here a advice that has absolutely no importance.

OK, -Xd does the trick because it does not give /lib nor /usr/lib as searh
path.

But I maintain that there is still a problem with crti.o and crtn.o

It is not normal that all other needed libraries are using the correct 32
bit path (/usr/lib32) and not crti.o and crtn.o

Normally, like for all other libraries, the system try to find in each
search path (begining with the first in list) the needed library with the
correct ELF 32 bit.

If the system find one that is ELF 64, it will try a other search path until
it discover a good ELF 32 bit.

But is seems that for crti.o and crtn.o if they are ELF  64, there are
recognized as ELF 32.

So IMHO it is a sytem problem (or is it fpc that does the search+test ELF
?).

OK, sure nobody did understand, so sorry for the noise.

Fre;D



--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

mse
Administrator
On Sunday 22 July 2018 23:06:13 fredvs wrote:

> Re-hello.
>
> Here a advice that has absolutely no importance.
>
> OK, -Xd does the trick because it does not give /lib nor /usr/lib as searh
> path.
>
> But I maintain that there is still a problem with crti.o and crtn.o
>
> It is not normal that all other needed libraries are using the correct 32
> bit path (/usr/lib32) and not crti.o and crtn.o
>
> Normally, like for all other libraries, the system try to find in each
> search path (begining with the first in list) the needed library with the
> correct ELF 32 bit.
>
> If the system find one that is ELF 64, it will try a other search path
> until it discover a good ELF 32 bit.
>
> But is seems that for crti.o and crtn.o if they are ELF  64, there are
> recognized as ELF 32.
>
In INPUT statement there are absolute paths for crtend.o and crtn.o.
"
/usr/lib32/crtend.o
/lib/crtn.o <<<--- wrong
"
and
"
/usr/lib32/crtend.o
/usr/lib32/crtn.o
"
I don't know how FPC decides which one of the found modules to use so it is
better to add -Xd.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

Sieghard
In reply to this post by fredvs
Hello fredvs,

Sie schrieben am Sun, 22 Jul 2018 16:06:13 -0500 (CDT):

> It is not normal that all other needed libraries are using the correct 32
> bit path (/usr/lib32) and not crti.o and crtn.o

It seems normal -

> Normally, like for all other libraries, the system try to find in each
> search path (begining with the first in list) the needed library with the
> correct ELF 32 bit.
>
> If the system find one that is ELF 64, it will try a other search path
> until it discover a good ELF 32 bit.
>
> But is seems that for crti.o and crtn.o if they are ELF  64, there are
> recognized as ELF 32.

- considering, that these two _object_ files seem to be multi architacture
in systems with multi architecture support.

> So IMHO it is a sytem problem (or is it fpc that does the search+test ELF
> ?).

You're _certain_ that these files are really multi-arch and were not
replaced by single-arch files by a previous update?

BTW, on my system, the lib32-versions of crti.o and crtn.o evidently are
_not_ multi-arch, but 32bit only.

But I must admit that I do not know whether fpc uses the system linker "ld"
(which I used to find the above mentioned things) or has one integrated into
itself.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Hello Seighard.

> - considering, that these two _object_ files seem to be multi architacture
> in systems with multi architecture support.

Not sure to understand.
Do you mean that it exist object_ files that have both ELF32+64 signatures ?
And then only one file could be used in a multi-arch system ?
If so, I did not know that such object_ files exist.

> You're _certain_ that these files are really multi-arch and were not
> replaced by single-arch files by a previous update?

Not sure of course.
I am only sure that I did install 2 days ago Linux ManJaro + enabled
multi-arch 64+32.
And running fpc32 on that 64 bit OS raise a error at linking because of
those 2 crti.o and crtn.o files.

> BTW, on my system, the lib32-versions of crti.o and crtn.o evidently are
> _not_ multi-arch, but 32bit only.

Here also on Manjaro (Arch OS) the 32 bit crti.o and crtn.o are in
/usr/lib32 and do have a ELF signature of 32 bit.
And crti.o and crtn.o that are in /lib (smartlink to /usr/lib ) are clearly
64 bit (but maybe I miss something about ELF64+32)

Now only for the sport, I would like to understand why those
/usr/lib/crti.o+crtn.o (with 64 bit ELF sign) are used by fpc.

Take a look at fpc source t_linux.pas line 508 :

StartSection('INPUT(');
 if linklibc and (libctype<>uclibc) then
       begin
         { crti.o must come first }
         if librarysearchpath.FindFile('crti.o',false,s) then // NOT GOOD,
WHY ?
           AddFileName(s)
         else
           Message1(exec_w_init_file_not_found,'crti.o');
 
  { then the crtbegin* }
         if cs_create_pic in current_settings.moduleswitches then
           begin
             if librarysearchpath.FindFile('crtbeginS.o',false,s) then //
HERE GOOD, LIKE ALL OTHERS
               AddFileName(s)
             else
               Message1(exec_w_init_file_not_found,'crtbeginS.o');
           end
         else
....

Why librarysearchpath assign a ELF 64 to crti.o' (and ctri.o)  but the good
ELF 32 to all others ?

Strange...

By the way, many thanks Seighard for your attention.

Fre;D





--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

Sieghard
Hello fredvs,

Sie schrieben am Tue, 24 Jul 2018 07:41:42 -0500 (CDT):

> Hello Seighard.
         ^^ie
(Doesn't your editor extract this from the cited posting?)

> > - considering, that these two _object_ files seem to be multi
> > architacture in systems with multi architecture support.  
>
> Not sure to understand.
> Do you mean that it exist object_ files that have both ELF32+64
> signatures ? And then only one file could be used in a multi-arch system ?

Yes, that's how it looked to me after a few tests with the system linker
on my machine, set up for multi-arch support, because I have to build -
and built successfully several times before - 32-bit fpc / mse programs
at times.

> If so, I did not know that such object_ files exist.

I was surprised also that the linker did only accept the files from lib64,
but complained about those from lib32, independent of the requested target
architecture (both under /usr/, I don't have any crt*.o under /lib at all -
maybe these are links to those in /usr/lib64 on your system?).

> > You're _certain_ that these files are really multi-arch and were not
> > replaced by single-arch files by a previous update?  

But now, after some more more thorough testing, this seems to have been a
false impression.
I probabely didn't use the correct option for this kind of work yesterday,
which caused the linker to happily ignore the architecture settings I gave
it and always produce 64-bit files. The correct option to produce 32-bit
output ist "-m elf_i386" ("m" for "emulation"), and using this, it does
require the 32-bit crt*.o files to be provided and outputs a real 32-bit
elf program.
This architecture switching and cross compiling stuff certainly is somewhat
tricky...

> I am only sure that I did install 2 days ago Linux ManJaro + enabled
> multi-arch 64+32.
> And running fpc32 on that 64 bit OS raise a error at linking because of
> those 2 crti.o and crtn.o files.

So it looks like the /lib/crt*.o files of this installation keep the linker
from searching for and finding the right files in the right directory.
You might attempt to try removing them (making sure you can reinstall them)
and see whether building your 32-bit program succeeds then.
This deviation from common practice might be regarded as a bug, at least as
an idiosyncrasy, of Manjaro then.

Anyway, whether you continue trying or just use the work around you found
already, it's probabely my turn to beg for pardon for the noise...

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Hello Sieghard.

Thanks for your time.

Huh, yes, using 32 bit apps on multi-arch 64 bit system can be ***very***
painful.

At the moment I can successfully run fpc32 (on a 64 bit os) and compile 32
bit applications.
Yesterday, I was even able to run those 32 applications on the multi-arch os
!

But sadly, today I did something wrong and the 32 bit applications fail to
run on the multi-arch os.
(The good news is that those applications run perfectly on a mono-arch 32
bit system.)

About the ctri.o and ctrn.o problems, the -Xd parameter fixes the linking
(but I did not find why the 64 bit object-files are assigned in place of 32
bit).

>  it's probabely my turn to beg for pardon for the noise...

Please dont beg for pardon, I am already very happy that somebody did
understand the problem.

Thanks Sieghard.

Fre;D




--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

mse
Administrator
On Wednesday 25 July 2018 21:58:25 fredvs wrote:

>
> About the ctri.o and ctrn.o problems, the -Xd parameter fixes the linking
> (but I did not find why the 64 bit object-files are assigned in place of 32
> bit).
>
Because in linker script are absolute paths, see my mail from 2018-07-23:

"

> > But is seems that for crti.o and crtn.o if they are ELF  64, there are
> > recognized as ELF 32.
>
> In INPUT statement there are absolute paths for crtend.o and crtn.o.
> "
> /usr/lib32/crtend.o
> /lib/crtn.o <<<--- wrong
> "
> and
> "
> /usr/lib32/crtend.o
> /usr/lib32/crtn.o
> "
> I don't know how FPC decides which one of the found modules to use so it is
> better to add -Xd.
"
I assume the reason must be searched in FPC code.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
Hello Martin.

> Because in linker script are absolute paths, see my mail from 2018-07-23:

Huh, OK, I did read it but the code for the linker script is in  t_linux.pas
line 508 (see my post of Jul 24, 2018; 2:41pm)

StartSection('INPUT(');
 if linklibc and (libctype<>uclibc) then
       begin
         { crti.o must come first }
         if librarysearchpath.FindFile('crti.o',false,s) then // NOT GOOD
           AddFileName(s)
         else
           Message1(exec_w_init_file_not_found,'crti.o');
 
  { then the crtbegin* }
         if cs_create_pic in current_settings.moduleswitches then
           begin
             if librarysearchpath.FindFile('crtbeginS.o',false,s) then //
HERE GOOD
               AddFileName(s)
             else
               Message1(exec_w_init_file_not_found,'crtbeginS.o');
           end
         else
...

You may see that the absolute path is the same for all files, why only
'crti.o' and 'crtn.o' get the wrong path ?

> I assume the reason must be searched in FPC code.

Yes at first look it is what I think but, after searching in FPC code, it is
not so clear that FPC is the guilty.
IMHO there is problem with the os that does not recognize the good 32 bit
ELF for those 2 files.

But, OK, thanks for your light (and better to forget that bug
fixed-by-Xd-workaround).

Fre;D






--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
mse
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

mse
Administrator
On Thursday 26 July 2018 14:11:11 fredvs wrote:

> Hello Martin.
>
> > Because in linker script are absolute paths, see my mail from 2018-07-23:
>
> Huh, OK, I did read it but the code for the linker script is in
> t_linux.pas line 508 (see my post of Jul 24, 2018; 2:41pm)
>
> StartSection('INPUT(');
>  if linklibc and (libctype<>uclibc) then
>        begin
>          { crti.o must come first }
>          if librarysearchpath.FindFile('crti.o',false,s) then // NOT GOOD

Maybe librarysearchpath has an entry for /lib where on your system a 64 bit
crtn.o is located?
>
> But, OK, thanks for your light (and better to forget that bug
> fixed-by-Xd-workaround).
>
I don't think it is a workaround. -Xd is necessary if in the default library
paths object files with the correct name but wrong arch are available.

Martin

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
> Maybe librarysearchpath has an entry for /lib where on your system a 64 bit
crtn.o is located?

It is exactly wath I was thinking but... I did not found this in FPC code.

Fre;D



--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
Reply | Threaded
Open this post in threaded view
|

Re: [MSEide-MSEgui-talk] Multi-arch problem...

fredvs
In reply to this post by mse
Re-hello.

> Maybe librarysearchpath has an entry for /lib where on your system a 64
> bit crtn.o is located?

Re-about this, even if librarysearchpath has an entry for /lib (that I did
not found), normally, like for all other libraries, it seems to me that
there is a check if the file has the correct ELF 32 bit signature.

And if the signature is 64 bit, it should look for a other path into the
search-path list.

But maybe I miss something.

Fre;D



--
Sent from: http://mseide-msegui-talk.13964.n8.nabble.com/

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
mseide-msegui-talk mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
12