Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
glibc-3X broke backward compat for modelsim [solved for now]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Mon Jul 06, 2020 10:08 pm    Post subject: glibc-3X broke backward compat for modelsim [solved for now] Reply with quote

And I can't run an ancient (four years old) 32 bit binary called Model Sim.

And 2.29 has disappeared from portage... I had previously masked off 2.30, but 2.31 came along and killed me.

Is there anyway to make this work without running a VM?
_________________
Some day there will only be free software.


Last edited by RayDude on Tue Jul 07, 2020 4:47 pm; edited 1 time in total
Back to top
View user's profile Send private message
Princess Nell
l33t
l33t


Joined: 15 Apr 2005
Posts: 808

PostPosted: Mon Jul 06, 2020 11:01 pm    Post subject: Reply with quote

Use git.

This is the commit that dropped it: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a98db11637ac67d5a244678db470d2e1837a9386.

Try this rev: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc?id=e0bec9afbe073dd9ad9b97172385b1a268352e05

I'm surprised a four year old binary won't work. My system is now on glibc 2.30 and I can still run a 32-bit binary I built 2004 under SuSE 8.2 (IIRC). I need to keep a copy of libstdc++-v3 around for it, too, which is about to be removed.
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 2348
Location: Frankfurt, Germany

PostPosted: Tue Jul 07, 2020 12:22 am    Post subject: Reply with quote

Emerge says: Downgrading glibc is not supported and a sure way to destruction.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15818

PostPosted: Tue Jul 07, 2020 12:34 am    Post subject: Reply with quote

What exactly broke this program? You may be able to locally revert the breaking change, or even argue for an upstream revert.

How did the introduction of glibc-2.31 matter to glibc-2.30? Did you use a mask specifically on =2.30, instead of >=2.30?
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 1:16 am    Post subject: Reply with quote

Hu wrote:
What exactly broke this program? You may be able to locally revert the breaking change, or even argue for an upstream revert.

How did the introduction of glibc-2.31 matter to glibc-2.30? Did you use a mask specifically on =2.30, instead of >=2.30?


I think 2.30 was unstable and 2.31 became stable... I looked and I hadn't actually masked 2.30, so I figure that's how it happened.

I'm not sure I understand why 'vish' isn't running anymore. It's so cobbled with old binaries shoved in it's own lib folder that it's hard to tell what's really going on.

The error message that is new is only visible from gdb:

Code:
Reading symbols from /opt/intelFPGA/19.1/modelsim_ae/bin/../linux/vsim...
(No debugging symbols found in /opt/intelFPGA/19.1/modelsim_ae/bin/../linux/vsim)
(gdb) run
Starting program: /opt/intelFPGA/19.1/modelsim_ae/linuxaloem/vsim -mvchome /opt/intelFPGA/19.1/ip/altera/mentor_vip_ae/common -dpicpppath /usr/bin/gcc
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 14950]
process 14946 is executing new program: /opt/intelFPGA/19.1/modelsim_ae/linuxaloem/vish
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[Detaching after vfork from child process 14956]
[Detaching after vfork from child process 14958]
Reading pref.tcl

Program received signal SIGSEGV, Segmentation fault.
0xf7b0acd3 in _IO_file_seekoff () from /lib/libc.so.6

_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 1:27 am    Post subject: Reply with quote

Princess Nell wrote:
Use git.

This is the commit that dropped it: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a98db11637ac67d5a244678db470d2e1837a9386.

Try this rev: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc?id=e0bec9afbe073dd9ad9b97172385b1a268352e05

I'm surprised a four year old binary won't work. My system is now on glibc 2.30 and I can still run a 32-bit binary I built 2004 under SuSE 8.2 (IIRC). I need to keep a copy of libstdc++-v3 around for it, too, which is about to be removed.


I posted the actual gdb message up above...

Code:
0xf7b0acd3 in _IO_file_seekoff () from /lib/libc.so.6


This is all intel's fault. They haven't even bothered to port their code to 64 bit platforms. I suspect that's because they don't actually own it, they just had mentor make a special version for them...
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15818

PostPosted: Tue Jul 07, 2020 3:50 am    Post subject: Reply with quote

sys-libs/glibc-2.30-r8 is stable on both amd64 and x86.

That gdb output is not sufficient to understand the problem. A backtrace might help.
Back to top
View user's profile Send private message
Ionen
Veteran
Veteran


Joined: 06 Dec 2018
Posts: 1101

PostPosted: Tue Jul 07, 2020 6:38 am    Post subject: Reply with quote

Seems ArchLinux even suggests using glibc 2.23 with it and use LD_LIBRARY_PATH to load it.

Given it looks sensitive about other things and the whole 32-bit mess, personally I'd just toss the entire environment it wants in a chroot and never update it (or a VM, but you did say you wanted to avoid that.. not that chroot is far off). Definitely don't cling to a old glibc version for your main proper system.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 2:43 pm    Post subject: Reply with quote

Hu wrote:
sys-libs/glibc-2.30-r8 is stable on both amd64 and x86.

That gdb output is not sufficient to understand the problem. A backtrace might help.


Here's a backtrace:

Code:
Program received signal SIGSEGV, Segmentation fault.
0xf7b0acd3 in _IO_file_seekoff () from /lib/libc.so.6
(gdb) bt
#0  0xf7b0acd3 in _IO_file_seekoff () from /lib/libc.so.6
#1  0xf7b0c564 in _IO_file_attach () from /lib/libc.so.6
#2  0xf7b07a82 in ?? () from /lib/libc.so.6
#3  0xf7ae3a17 in dprintf () from /lib/libc.so.6
#4  0xf7bc83a1 in ?? () from /lib/libc.so.6
#5  0xf7bc842d in _dl_signal_exception () from /lib/libc.so.6
#6  0xf7fed59b in ?? () from /lib/ld-linux.so.2
#7  0xf7fde8d0 in ?? () from /lib/ld-linux.so.2
#8  0xf7fe364a in ?? () from /lib/ld-linux.so.2
#9  0xf7fe9130 in ?? () from /lib/ld-linux.so.2
#10 0xf7cb712e in FcFreeTypeQueryAll () from /usr/lib/libfontconfig.so.1
#11 0xf7cb1b78 in ?? () from /usr/lib/libfontconfig.so.1
#12 0xf7cb1f35 in ?? () from /usr/lib/libfontconfig.so.1
#13 0xf7cb216a in ?? () from /usr/lib/libfontconfig.so.1
#14 0xf7cacf47 in ?? () from /usr/lib/libfontconfig.so.1
#15 0xf7cad006 in FcConfigBuildFonts () from /usr/lib/libfontconfig.so.1
#16 0xf7cb808f in ?? () from /usr/lib/libfontconfig.so.1
#17 0xf7cb80ba in FcInitLoadConfigAndFonts () from /usr/lib/libfontconfig.so.1
#18 0xf7ca9b94 in ?? () from /usr/lib/libfontconfig.so.1
#19 0xf7cb8145 in FcInitBringUptoDate () from /usr/lib/libfontconfig.so.1
#20 0xf7cbb0b5 in FcFontList () from /usr/lib/libfontconfig.so.1
#21 0xf7d071e2 in XftListFonts () from /usr/lib/libXft.so.2
#22 0x08482eac in ?? ()
#23 0x083f7584 in ?? ()
#24 0x084cc422 in ?? ()
#25 0x0851503f in ?? ()
#26 0x0851d9e1 in ?? ()
#27 0x084ce5a1 in TclEvalObjEx ()
#28 0x084e3a71 in ?? ()
#29 0x084cc422 in ?? ()
#30 0x0851503f in ?? ()
#31 0x0855ca2a in TclObjInterpProcCore ()
#32 0x0855cfc7 in TclObjInterpProc ()
#33 0x084cc422 in ?? ()
#34 0x0851503f in ?? ()
#35 0x0855ca2a in TclObjInterpProcCore ()
#36 0x0855cfc7 in TclObjInterpProc ()
#37 0x084cc422 in ?? ()
#38 0x0851503f in ?? ()
#39 0x0855ca2a in TclObjInterpProcCore ()


If I put the old 32 bit glibc binary in vsim's own lib folder, then it starts complaining about libpthread. If I copy it, then it complains about something else.
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 2:45 pm    Post subject: Reply with quote

Ionen wrote:
Seems ArchLinux even suggests using glibc 2.23 with it and use LD_LIBRARY_PATH to load it.

Given it looks sensitive about other things and the whole 32-bit mess, personally I'd just toss the entire environment it wants in a chroot and never update it (or a VM, but you did say you wanted to avoid that.. not that chroot is far off). Definitely don't cling to a old glibc version for your main proper system.


Thanks. I have a 32 bit chroot for running the license manager. I ended up getting a 64 bit version working with the help of intel support.

I guess I'll try to build up the chroot that's from december and see if I can get it working there. Running centos 7 feels like marching back into the stone age.

Thanks everyone for helping, I really appreciate it.
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 4:37 pm    Post subject: Reply with quote

It looks like I got it working. GUI ran, I have to verify it simulates, but before I get back to work I want to document how I did it here.

I went through and figured out which libraries had to be downgraded / copied to the model sim's local lib directory.

After I put an old 32 bit glibc in the local lib folder, I got this message: /usr/lib/libfontconfig.so.1: undefined symbol: FT_Done_MM_Var.

To fix that I had to compile my own libfontconfig. Thanks to this post: https://j-marjanovic.io/new-ubuntu-old-problems-with-modelsim.html I knew how.

vco, the model sim startup script, has to be modified as well. But those of us who keep this code running know all about that.

To get (vsim, modelsim, vish) running the lib directory needs to contain these files:

Code:
fire /opt/intelFPGA/19.1/modelsim_ae/lib # ls -lah
total 6.3M
drwxr-xr-x  2 root root 4.0K Jul  7 09:19 .
drwxr-xr-x 35 root root 4.0K Jun  3 09:19 ..
-rwxr-xr-x  1 root root 1.9M Jul  7 08:24 libc-2.29.so
lrwxrwxrwx  1 root root   12 Jul  7 08:24 libc.so.6 -> libc-2.29.so
lrwxrwxrwx  1 root root   23 Jul  7 09:19 libfontconfig.so -> libfontconfig.so.1.10.1
lrwxrwxrwx  1 root root   23 Jul  7 09:19 libfontconfig.so.1 -> libfontconfig.so.1.10.1
-rwxr-xr-x  1 root root 279K Jul  7 09:19 libfontconfig.so.1.10.1
-rw-r--r--  1 root root 731K Jun  3 09:35 libfreetype.a
-rwxr-xr-x  1 root root 631K Jun  3 09:35 libfreetype.so
-rwxr-xr-x  1 root root 631K Jun  3 09:35 libfreetype.so.6
-rwxr-xr-x  1 root root 631K Jun  3 09:35 libfreetype.so.6.10.2
-rwxr-xr-x  1 root root 157K Jul  7 08:25 libpthread-2.29.so
lrwxrwxrwx  1 root root   18 Jul  7 08:26 libpthread.so.0 -> libpthread-2.29.so
lrwxrwxrwx  1 root root   16 Jul  7 08:56 libxml2.so -> libxml2.so.2.9.9
lrwxrwxrwx  1 root root   16 Jul  7 08:56 libxml2.so.2 -> libxml2.so.2.9.9
-rwxr-xr-x  1 root root 1.4M Jul  7 08:58 libxml2.so.2.9.9


And to make things easy for myself in the future, I've tarred everything up and stuck it on google.

https://drive.google.com/file/d/12IlKdrmTddQ3ILDrAY9TaML4t42H6i8G/view?usp=sharing

Hopefully this will keep the software running for years to come.

Thanks everyone for your help.


Edit: for posterity, here is the important part of the diff file for vco:
(note: this is not complete as I do not have the original vco to compare to)

Code:
@@ -49,6 +49,8 @@
 
 dir=`dirname "$arg0"`
 
+export LD_LIBRARY_PATH=${dir}/lib
+
 vco=${uname}${utype}
 case $vco in
   SunOS4*)
@@ -206,7 +208,6 @@
           2.4.[1-9][0-9]*)  vco="linux" ;;
           2.[5-9]*)         vco="linux" ;;
           2.[1-9][0-9]*)    vco="linux" ;;
          3.[0-9]*)                vco="linux" ;;
+           *)                vco="linux" ;;
         esac
         if [ ! -x "$dir/$vco/vsim" ]; then
@@ -320,9 +321,10 @@
         #echo LD_LIBRARY_PATH=$LD_LIBRARY_PATH
     fi
 fi

_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 4:56 pm    Post subject: Reply with quote

Well. I spoke too soon.

Code:
** Fatal: Trouble with Simulation Kernel.

_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 6:38 pm    Post subject: Reply with quote

I used this command to run ModelSim until Saturday's upgrade:

Code:
vsim -mvchome /opt/intelFPGA/19.1/ip/altera/mentor_vip_ae/common -dpicpppath /usr/bin/gcc


That produces this error in the shell:

Code:
sh: line 1: 18959 Segmentation fault      "/opt/intelFPGA/19.1/modelsim_ae/gcc-4.7.4-linux/bin/g++" -dumpversion > '/tmp/questatmp.32BqPO' 2>&1


But if I run that command by hand, it works:

Code:
/opt/intelFPGA/19.1/modelsim_ae/gcc-4.7.4-linux/bin/g++ -dumpversion
4.7.4


Based on an error message in the GUI:

Code:
# ** Warning: (vsim-144) Detected unknown compiler '/opt/intelFPGA/19.1/modelsim_ae/gcc-4.7.4-linux/bin/g++'. Make sure that the CppPath INI file variable or the argument to the -cpppath option if set, is set to a path that exists
# No such file or directory. (errno = ENOENT)


If I set the path to my local gcc with:

Code:
vsim -mvchome /opt/intelFPGA/19.1/ip/altera/mentor_vip_ae/common -cpppath /usr/bin/gcc


The the GUI launches without error, but when I try to simulate I get the not so useful error message:

Code:
** Fatal: Trouble with Simulation Kernel.


Which according to google searches can imply everything from my source code having a signal undriven to any of a number of other issues.

I'm pretty sure this is related to gcc. I just don't understand why this would have changed. I've been running gcc-9.3 for a while now and I thought it was working...
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 6:55 pm    Post subject: Reply with quote

Here's the proof that it's a g++ problem:

Code:
[162394.415667] g++[354]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[162394.415670] Code: Bad RIP value.
[162744.926119] g++[1203]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[162744.926121] Code: Bad RIP value.
[163275.949013] g++[2728]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[163275.949016] Code: Bad RIP value.
[163884.441105] g++[16324]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[163884.441108] Code: Bad RIP value.
[164230.502340] g++[17091]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[164230.502343] Code: Bad RIP value.
[164346.470260] g++[24842]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[164346.470264] Code: Bad RIP value.
[164513.499600] g++[25237]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[164513.499602] Code: Bad RIP value.
[165588.414734] g++[15984]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[165588.414737] Code: Bad RIP value.
[167541.077003] g++[20673]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[167541.077006] Code: Bad RIP value.
[167691.258807] vsimk[21227]: segfault at 0 ip 0000000000000000 sp 00000000ffffaabc error 14 in vsimk[8048000+1d4b000]
[167691.258810] Code: Bad RIP value.
[167753.010288] g++[21401]: segfault at 0 ip 0000000000000000 sp 00000000ffffc3fc error 14 in g++[8048000+7c000]
[167753.010291] Code: Bad RIP value.
[167766.804174] vsimk[21549]: segfault at 0 ip 0000000000000000 sp 00000000ffffaa9c error 14 in vsimk[8048000+1d4b000]
[167766.804176] Code: Bad RIP value.
[172043.173423] g++[16704]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[172043.173426] Code: Bad RIP value.
[172235.810359] g++[17180]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[172235.810361] Code: Bad RIP value.
[172397.678706] g++[17692]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[172397.678709] Code: Bad RIP value.
[172453.971787] vsimk[17945]: segfault at 0 ip 0000000000000000 sp 00000000ffffaaec error 14 in vsimk[8048000+1d4b000]
[172453.971790] Code: Bad RIP value.
[172666.863114] g++[18501]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[172666.863117] Code: Bad RIP value.
[172807.511831] g++[18920]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[172807.511834] Code: Bad RIP value.
[172821.694423] g++[18959]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[172821.694426] Code: Bad RIP value.
[173284.074249] g++[19965]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[173284.074252] Code: Bad RIP value.
[173592.750930] vsimk[20835]: segfault at 0 ip 0000000000000000 sp 00000000ffffaaec error 14 in vsimk[8048000+1d4b000]
[173592.750933] Code: Bad RIP value.
[173976.392992] g++[21819]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[173976.392995] Code: Bad RIP value.
[173983.863792] g++[21840]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[173983.863795] Code: Bad RIP value.
[174182.134765] g++[22244]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[174182.134768] Code: Bad RIP value.
[174190.370557] g++[22298]: segfault at 0 ip 0000000000000000 sp 00000000ffffc42c error 14 in g++[8048000+7c000]
[174190.370559] Code: Bad RIP value.
[174537.826498] vsimk[23489]: segfault at 0 ip 0000000000000000 sp 00000000ffffaabc error 14 in vsimk[8048000+1d4b000]
[174537.826500] Code: Bad RIP value.


Now if I only knew what to do about it...
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 7:05 pm    Post subject: Reply with quote

Ah, if I specify the path to my gcc for both vlog and systemC, then the dmesg segfault I get is simply this:

Code:
[175394.077117] vsimk[25926]: segfault at 0 ip 0000000000000000 sp 00000000ffffaabc error 14 in vsimk[8048000+1d4b000]
[175394.077120] Code: Bad RIP value.


So vsimk is having problems. I wonder what problems they are.

It still feels related to gcc...

I have to test the gcc that comes with vsim.
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 8:45 pm    Post subject: Reply with quote

I have determined that one of the libraries I added is not compatible with vsimk, the vsim kernel. If I change ld_library_path in my bash shell, and then attempt to run vsimk, I get the seg fault I see when the GUI is running.

I'm assuming glibc is okay because that version had been working... But I wonder if that's a bogus assumption...

Oh well. At least I have a lead.
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 8:57 pm    Post subject: Reply with quote

So, I don't get it...

If I remove the special glibc and the libpthread that I put in the modelsim_ae/lib directory and then run vsimk directly, it works...

Code:
export LD_LIBRARY_PATH=/opt/intelFPGA/19.1/modelsim_ae/lib
/opt/intelFPGA/19.1/modelsim_ae/linuxaloem/vsimk


I'm running a simulation at the moment. It looks like it's working...

I wonder why I can't start it with the vco script... The vco script must be doing something wrong. I bet I broke it.
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Tue Jul 07, 2020 9:08 pm    Post subject: Reply with quote

vsim and vsimk are different executables. I'm skipping vsim and running vsimk directly. That is the difference. I wonder if they were built differently...
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
RayDude
Veteran
Veteran


Joined: 29 May 2004
Posts: 1683
Location: San Jose, CA

PostPosted: Wed Jul 08, 2020 4:11 pm    Post subject: Reply with quote

Final Update.

Things I've discovered:

1. Don't need old glibc. I think the failure occurred because of an updated libfontconfig. Not sure though. It may be related to how libfontconfig uses glibc.
2. Don't need old libpthread.
3. This version of model sim is 32 bit only, despite the vco script mentioning the existence of a 64 bit version.
4. The reason it wouldn't run after I built libfontconfig seems to be related to the fact that I was specifying my local gcc. Once I removed those command line options, the tool runs fine through vco.
5. I also cannot run vsim (the linke to vco) with a trailing ampersand (&). For some reason trying to run it in the background does not launch the tool. This may be related to the various errors fontconfig generates over my new format /etc/fonts/conf.d/ directory.

There may be something else going on that I missed.
_________________
Some day there will only be free software.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum