Using 13.2-RELEASE with lang/gcc version 12_5 on Pi model 4, I get the following error. The same test on an amd desktop pc using the same OS and pkg works fine. <CODE> [freebsd@generic ~]$ cat helloworld.cpp #include <stdio.h> int main (int ac, char *av[]) { printf ("hello world\n"); return (0); } [freebsd@generic ~]$ g++ -o helloworld{,.cpp} [freebsd@generic ~]$ ./helloworld ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc12/libstdc++.so.6 not found </CODE>
Hmm, this is not specific to lang/gcc which is only a "shell", but comes from lang/gcc12 which it redirects to on your system looking at the reference to /usr/local/lib/gcc12/libstdc++.so.6. Lorenzo, do you have an idea? Elwood, which GCC-related ports do you have installed? (Output of `pkg info | grep gcc` for example.)
Hi Gerald, Not much, this is a fresh install. [freebsd@generic ~]$ pkg info | grep gcc gcc-12_5 Meta-port for the default version of the GNU Compiler Collection gcc12-12.2.0_6 GNU Compiler Collection 12 freebsd@generic ~]$
FYI, I just happened to notice if I compile with gcc then it runs fine. [freebsd@generic ~]$ gcc helloworld.cpp [freebsd@generic ~]$ ./a.out hello world [freebsd@generic ~]$ g++ helloworld.cpp [freebsd@generic ~]$ ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/local/lib/gcc12/libstdc++.so.6 not found [freebsd@generic ~]$
(In reply to Elwood Downey from comment #3) > FYI, I just happened to notice if I compile with gcc then it runs fine. This is because it's not really a C++ program, rather part of the common subset between C and C++. g++ pulls in libstdc++, gcc does not.
Ok, just thought I'd mention it, wasn't sure how these tool chains work under the hood. The real program I want to build is about 100k lines of heavy-duty C++ for sure :-) Trying to build that is how I found this. I'm glad I could reproduce it with such a simple test case. I imagine it's just something like a missing symlink somewhere. Anyway, many thanks for working on it for me.
readelf -a /usr/local/lib/gcc11/libstdc++.so.6 | grep GCC_4.5.0 libstdc++.so.6 on gcc11 or gcc12 uses __unordtf2@GCC_4.5.0 (on aarch64) __unordtf2 is put under GCC_4.6.0 on FreeBSD [1] and GCC_4.5.0 on gcc [2], relevant commit on FreeBSD [3] [1] https://cgit.freebsd.org/src/tree/lib/libgcc_s/Symbol.map#n179 [2] https://github.com/gcc-mirror/gcc/blob/releases/gcc-12.3.0/libgcc/libgcc-std.ver.in#L1912 [3] https://cgit.freebsd.org/src/commit/lib/libgcc_s/Symbol.map?id=790a6be5a1699291c6da87871426d0c56dedcc89
Thanks for the report. I have started investigating on this, but I am also working on updating GCC default version on FreeBSD to 13 and this is higher priority. This is also because bugs such as this one might have been already fixed upstream. Thus I would like to ask you if you can test the issue with lang/gcc13 too. Testing the latest version of lang/gcc12, which will come once https://bz-attachments.freebsd.org/attachment.cgi?id=246177 is committed, would also be interesting. Please remember to disable LTO_BOOTSTRAP if this option is too heavy on the raspberry pi resources. Thanks.
(In reply to Lorenzo Salvadore from comment #7) This code hasn't changed on gcc master
(In reply to Mikael Urankar from comment #6) > __unordtf2 is put under GCC_4.6.0 on FreeBSD [1] and GCC_4.5.0 on gcc [2], > relevant commit on FreeBSD [3] : > [3] https://cgit.freebsd.org/src/commit/lib/libgcc_s/Symbol.map?id=790a6be5a1699291c6da87871426d0c56dedcc89 Looping in dim@ who committed that change. dim@, what do you advise? Is this something to adjust on the src side?
(In reply to Gerald Pfeifer from comment #9) The commit only defines version GCC_4.6.0, not GCC_4.5.0. I don't immediately recall how the patch came to be as it is, but the comment "Since gcc exports these under version GCC_4.6.0, we do the same" indicates that at the time, it looked like gcc would put the symbols under this version. For now, I guess the easiest workaround is to run the affected program with LD_LIBRARY_PATH set to /usr/local/lib/gcc12, or link it with -Wl,-rpath,/usr/local/lib/gcc12. Regarding the symbol versions themselves, I will take another look at the version maps that gcc uses, to see if we have to update the maps for our libgcc_s.so.
I confirm setting LD_RUN_PATH=/usr/local/lib/gcc12 then both the submitted test program and my real app build and run fine. This will do for now, many thanks to all.
Oops, you said LD_LIBRARY_PATH. I have been using LD_RUN_PATH while waiting for a resolution. But I just confirmed LD_LIBRARY_PATH works also.
So this is a bit weird. I just built the lang/gcc12 port, and looked in the wrkdir for the libgcc.map files (there's one for native, and one for 32-bit but that doesn't matter). There is no version GCC_4.5.0 in there at all: ... (begin elided) ... GCC_4.2.0 { global: _Unwind_GetIPInfo; __floatuntidf; __floatuntisf; __floatuntixf; } GCC_4.0.0; GCC_4.3.0 { global: __emutls_register_common; __bswapsi2; __emutls_get_address; __bswapdi2; } GCC_4.2.0; GCC_4.6.0 { global: __netf2; __multc3; __trunctfdf2; __trunctfxf2; __multf3; __addtf3; __extenddftf2; __extendsftf2; __extendxftf2; __floatsitf; __fixtfdi; __floatunsitf; __eqtf2; __fixunstfdi; __fixtfsi; __gttf2; __lttf2; __fixtfti; __divtc3; __divtf3; __unordtf2; __negtf2; __fixunstfsi; __fixunstfti; __floattitf; __trunctfsf2; __powitf2; __floatditf; __floatuntitf; __subtf3; __floatunditf; __getf2; __letf2; } GCC_4.3.0; ... (rest elided) ... The produced libgcc_s.so.1 also doesn't have 4.5.0: Version definition section '.gnu.version_d' contains 14 entries: Addr: 0x0000000000002110 Offset: 0x00002110 Link: 3 (.dynstr) 000000: Rev: 1 Flags: BASE Index: 1 Cnt: 1 Name: libgcc_s.so.1 0x001c: Rev: 1 Flags: none Index: 2 Cnt: 1 Name: GCC_3.0 0x0038: Rev: 1 Flags: none Index: 3 Cnt: 2 Name: GCC_3.3 0x0054: Parent 1: GCC_3.0 0x005c: Rev: 1 Flags: none Index: 4 Cnt: 2 Name: GCC_3.3.1 0x0078: Parent 1: GCC_3.3 0x0080: Rev: 1 Flags: none Index: 5 Cnt: 2 Name: GCC_3.4 0x009c: Parent 1: GCC_3.3.1 0x00a4: Rev: 1 Flags: none Index: 6 Cnt: 2 Name: GCC_3.4.2 0x00c0: Parent 1: GCC_3.4 0x00c8: Rev: 1 Flags: none Index: 7 Cnt: 2 Name: GCC_3.4.4 0x00e4: Parent 1: GCC_3.4.2 0x00ec: Rev: 1 Flags: none Index: 8 Cnt: 2 Name: GCC_4.0.0 0x0108: Parent 1: GCC_3.4.4 0x0110: Rev: 1 Flags: none Index: 9 Cnt: 2 Name: GCC_4.2.0 0x012c: Parent 1: GCC_4.0.0 0x0134: Rev: 1 Flags: none Index: 10 Cnt: 2 Name: GCC_4.3.0 0x0150: Parent 1: GCC_4.2.0 0x0158: Rev: 1 Flags: none Index: 11 Cnt: 2 Name: GCC_4.6.0 0x0174: Parent 1: GCC_4.3.0 0x017c: Rev: 1 Flags: none Index: 12 Cnt: 2 Name: GCC_4.7.0 0x0198: Parent 1: GCC_4.6.0 0x01a0: Rev: 1 Flags: none Index: 13 Cnt: 2 Name: GCC_4.8.0 0x01bc: Parent 1: GCC_4.7.0 0x01c4: Rev: 1 Flags: none Index: 14 Cnt: 2 Name: GCC_7.0.0 0x01e0: Parent 1: GCC_4.8.0 I really wonder where the original poster's libstdc++.so.6 came from? Is that from a quarterly ports build?
Oh, wait a minute, you are doing this on a arm64 platform. That might make the difference, as it looks like the gcc build dynamically generates its .map files from fragments, using some scripting. So it could very well be the case that arm64 builds of libgcc do include some symbols only versioned under 4.5.0. I'll see what happens when I do the same build in a arm64 VM.
(In reply to Dimitry Andric from comment #14) > So it could very well be the case that arm64 builds of libgcc do include > some symbols only versioned under 4.5.0. I'll see what happens when I do > the same build in a arm64 VM. Thank you, dim@! Did you already have a chance to look into this? Might be good to get this addressed for the next release (if applicable)?