FPGA editor in Fedora 11 x86_64
Jan Pech
based applications) running in Fedora 11, x86_64?
In RHEL, CentOS, and older versions of Fedora (all x86_64) it is
sufficient to set the $DISPLAY environment variable to :0 and to follow
this http://www.xilinx.com/support/answers/22022.htm answer record.
Unfortunately this does not work in F11/x86_64.
I get the same error messages as described in the answer record but the
answer itself does not help. According to "ldd -v ..../fpga_editor" I am
not missing any required library.
Thanks for your help,
Jan
anonymous anonymous
Please write an email or post it here if you found a solution. Thanks.
bitslipper <at> googlemail.com
General Schvantzkoph
The problem is that Fedora uses lesstif instead of motif. The solution is
to install a CentOS5.3 VM and run fpga_ed from there. Fedora 11 has KVM
built in, if you haven't already done it just install the virtualization
tools and then run virt-manager and install CentOS. You should do an NFS
export of your working directories on the host machine and then do an NFS
mount in the CentOS VM, that will allow you to operate on the same
directories in both the F11 host and the CentOS VM. I ssh into my CentOS
VM from Xemacs and run fpga editor from the ssh shell so, from a UI
standpoint, things that run on the VM are indistinguishable from things
that run on the host. Make sure that the NFS directories appear at the
same points in the file system on both the host and the client, that way
Xemacs can still do auto completion of file names and directories when
you are operating from the ssh shell.
KVM is the best VM option for F11. The performance of KVM is very very
close to native performance with Linux VMs. I've found that Windows VMs
are flaky on KVM, hopefully that will get fixed soon. VMware Server
doesn't run on .29 kernels, there is a patch but it doesn't work very
well. If you want to use VMware, which runs Windows VMs flawlessly and
runs Linux VMs just as well as KVM, you will have to stick with Fedora 10
until VMware adds support for .29 kernels. F10 uses the .27 kernel which
is fully supported by VMware.
anonymous anonymous
install the rpm package from www.motifzone.net. Then you have to
create a library link: "ln -s libXm.so.4 libXm.so.3". After that i had
to install libstdc++-4.4.0-4(x86_64). Finally there was a SELinux
issue:
SummarySELinux is preventing _fpga_editor from loading /opt/Xilinx/
10.1/ISE/lib/lin64/libkernel50.so which requires text relocation.
Detailed DescriptionThe _fpga_editor application attempted to load /
opt/Xilinx/10.1/ISE/lib/lin64/libkernel50.so which requires text
relocation. This is a potential security problem. Most libraries do
not need this permission. Libraries are sometimes coded incorrectly
and request this permission. The SELinux Memory Protection Tests web
page explains how to remove this requirement. You can configure
SELinux temporarily to allow /opt/Xilinx/10.1/ISE/lib/lin64/
libkernel50.so to use relocation as a workaround, until the library is
fixed. Please file a bug report against this package. Allowing
AccessIf you trust /opt/Xilinx/10.1/ISE/lib/lin64/libkernel50.so to
run correctly, you can change the file context to textrel_shlib_t.
"chcon -t textrel_shlib_t '/opt/Xilinx/10.1/ISE/lib/lin64/
libkernel50.so'" You must also change the default file context files
on the system in order to preserve them even on a full relabel.
"semanage fcontext -a -t textrel_shlib_t '/opt/Xilinx/10.1/ISE/lib/
lin64/libkernel50.so'"
After that FPGA Editor starts, but with several error messages:
[root@mobile lin64]# fpga_editor
/opt/Xilinx/10.1/ISE/bin/lin64/_fpga_editor: Symbol
`_XtperDisplayList' causes overflow in R_X86_64_PC32 relocation
/opt/Xilinx/10.1/ISE/bin/lin64/_fpga_editor: Symbol
`_XtGetPerDisplayInput' causes overflow in R_X86_64_PC32 relocation
Wind/U Error (248): Failed to connect to the registry on server mobile
Warning!!: XKEYSYMDB environment variable is set to a wrong location
glen herrmannsfeldt
(snip)
< SummarySELinux is preventing _fpga_editor from loading /opt/Xilinx/
< 10.1/ISE/lib/lin64/libkernel50.so which requires text relocation.
< Detailed DescriptionThe _fpga_editor application attempted to load /
< opt/Xilinx/10.1/ISE/lib/lin64/libkernel50.so which requires text
< relocation. This is a potential security problem. Most libraries do
< not need this permission. Libraries are sometimes coded incorrectly
< and request this permission. The SELinux Memory Protection Tests web
< page explains how to remove this requirement. You can configure
< SELinux temporarily to allow /opt/Xilinx/10.1/ISE/lib/lin64/
< libkernel50.so to use relocation as a workaround, until the library is
< fixed. Please file a bug report against this package. Allowing
< AccessIf you trust /opt/Xilinx/10.1/ISE/lib/lin64/libkernel50.so to
< run correctly, you can change the file context to textrel_shlib_t.
< "chcon -t textrel_shlib_t '/opt/Xilinx/10.1/ISE/lib/lin64/
< libkernel50.so'" You must also change the default file context files
< on the system in order to preserve them even on a full relabel.
< "semanage fcontext -a -t textrel_shlib_t '/opt/Xilinx/10.1/ISE/lib/
< lin64/libkernel50.so'"
Yes, I found this previously and even sent a note to Xilinx
about it. I haven't heard if there is interest in fixing it.
-- glen
Uwe Bonnes
> Yes, I found this previously and even sent a note to Xilinx
> about it. I haven't heard if there is interest in fixing it.
I fear that these note normally get lost in the dungle of first, second and
higher level support. First level support dooesn't understand _anything_
from the technical things we report and perhaps "translates" the report into
some other form, dropping the technical findings. Higher level doesn't
understand that translation and drops probably the report or "fixed" it in
some strange way, but not the real cause.
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Yes, I found this previously and even sent a note to Xilinx
>> about it. I haven't heard if there is interest in fixing it.
> I fear that these note normally get lost in the dungle of first, second and
> higher level support. First level support dooesn't understand _anything_
> from the technical things we report and perhaps "translates" the report into
> some other form, dropping the technical findings. Higher level doesn't
> understand that translation and drops probably the report or "fixed" it in
> some strange way, but not the real cause.
>
Most likely true. I sent it to what I was told was the right
person, but maybe not. I did not follow up.
At first, I (and some others) believed that it was intentional
on Xilinx part not to support webpack on x86_64 machines.
In my case, I ended up installing on an IA32 machine and copying
the whole directory tree over. The install program won't even
start, I believe due to the same effect. When actually running,
the selinux message came up, but only after the system actually
started running.
-- glen
Jan Pech
I have libstdc++ installed as well as openmotif. The SELinux is disabled
in all my desktop installations as it brings more problems than
benefits. Still I cannot start the fpga_editor at all. I am getting one
more additional error compared to you:
Wind/U Error (193): X-Resource: DefaultGUIFontSpec
(-*-helvetica-medium-r-normal-*-14-*) does not fully specify a font set
for this locale
Could that be the problem?
Jan
General Schvantzkoph
Add the xorg-x11 fonts packages.
Jan Pech
> > in all my desktop installations as it brings more problems than
> > benefits. Still I cannot start the fpga_editor at all. I am getting one
> > more additional error compared to you:
> >
> > Wind/U Error (193): X-Resource: DefaultGUIFontSpec
> > (-*-helvetica-medium-r-normal-*-14-*) does not fully specify a font set
> > for this locale
> >
> > Could that be the problem?
> >
> > Jan
>
> Add the xorg-x11 fonts packages.
Thank you, this was the problem. The old X11 fonts are not installed in
Fedora 11 by default.
Jan
General Schvantzkoph
I ran into that problem with Xemacs. They've added the dependency to the
Xemacs package, that might still be in testing.