date:20151209

Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

2015-12-09 Thread Mark Millard

[This time I'm explicit about a patch-gcc-freebsd-powerpc64 update and I report 
that with the change the PowerMac G5 hosted powerpc64-gcc based buildworld 
attempt completed, including WITH_LIB32= and WITH_BOOT= being involved. (But it 
may not be until tomorrow or later until I test if such a build actually works 
for installworld and reboot.)]

> On 2015-Dec-6, at 2:44 PM, Andreas Tobler  wrote:
> 
> On 06.12.15 22:34, Mark Millard wrote:
>> [I picked the lists that I did because powerpc64-gcc is the external
>> toolchain created to allow modern powerpc64 builds.]
>> 
>> For the powerpc64-gcc 5.2 vintages. . . (using my environment's path
>> as an example)
>> 
>> /usr/obj/portswork/usr/ports/devel/powerpc64-gcc/work/gcc-5.2.0/gcc/config/rs6000/freebsd64.h
>> has:
>> 
>>> /* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults
>>> instead.  */ #undef WCHAR_TYPE #define WCHAR_TYPE
>>> (TARGET_64BIT ? "int" : "long int") #undef  WCHAR_TYPE_SIZE #define
>>> WCHAR_TYPE_SIZE 32
>> 
>> That type in quotes ends up being the base type for L". . ."
>> notation, for example. Probably the char notation as well (L'?').
>> 
>> For FreeBSD Char compatibility in a powerpc64 lib32 context that
>> "long int" should effectively instead be "int", making the
>> conditional above technically unnecessary.
>> 
>> This blocks compiling lib32 source code that uses such notations as
>> L". . .": "long int" is not compatible with FreeBSD's Char in the
>> powerpc64 environment's 32 bit environment. Some compiler message are
>> explicit about the base types of pointers that result for the
>> mismatches: that is how I know that "long int" is in use for L". . ."
>> and "int" is the other base type involved.
>> 
>> (Yes, freebsd64.h appears to be used for lib32, at least on
>> powerpc64.  By contrast freebsd.h agrees for the WCHAR_TYPE_SIZE but
>> only undef's WCHAR_TYPE, presuming gcc defaults are correct for
>> FreeBSD as far as the type goes. It might need a more explicit type
>> to be sure of a Char match for that freebsd.h file's context.)
>> 
>> The 4.9 vintages of powerpc64-gcc were messed up the same way, as was
>> noted at the time.
> 
> I'll take care.
> 
> Andreas

(I make no claim that this note manages to preserve tabs and such in the diff 
-u text.)

To turn my earlier note into an actual updated 
devel/powerpc64-gcc/files/patch-gcc-freebsd-powerpc64 instead of the more vague 
words would involve adding what would look something like:

> @@ -304,7 +317,7 @@
>  
>  /* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults instead.  
> */
>  #undef WCHAR_TYPE
> -#defineWCHAR_TYPE  (TARGET_64BIT ? "int" : "long int")
> +#defineWCHAR_TYPE  "int"
>  #undef  WCHAR_TYPE_SIZE
>  #define WCHAR_TYPE_SIZE 32
> 

(It is what I actually tested.)

The full patch-gcc-freebsd-powerpc64 would then look something like:

> --- gcc/config/rs6000/freebsd64.h.orig  2015-01-05 04:33:28.0 -0800
> +++ gcc/config/rs6000/freebsd64.h   2015-12-09 00:14:28.520684000 -0800
> @@ -65,6 +65,13 @@
>  #define INVALID_64BIT "-m%s not supported in this configuration"
>  #define INVALID_32BIT INVALID_64BIT
>  
> +/* Use LINUX64 instead of FREEBSD64 for compat with e.g. sysv4le.h */
> +#ifdef LINUX64_DEFAULT_ABI_ELFv2
> +#define ELFv2_ABI_CHECK (rs6000_elf_abi != 1)
> +#else
> +#define ELFv2_ABI_CHECK (rs6000_elf_abi == 2)
> +#endif
> +
>  #undef  SUBSUBTARGET_OVERRIDE_OPTIONS
>  #define SUBSUBTARGET_OVERRIDE_OPTIONS  \
>do   \
> @@ -84,6 +91,12 @@
>   rs6000_isa_flags &= ~OPTION_MASK_RELOCATABLE; \
>   error (INVALID_64BIT, "relocatable"); \
> }   \
> + if (ELFv2_ABI_CHECK)  \
> +   {   \
> + rs6000_current_abi = ABI_ELFv2;   \
> + if (dot_symbols)  \
> +   error ("-mcall-aixdesc incompatible with -mabi=elfv2"); \
> +   }   \
>   if (rs6000_isa_flags & OPTION_MASK_EABI)  \
> {   \
>   rs6000_isa_flags &= ~OPTION_MASK_EABI;\
> @@ -304,7 +317,7 @@
>  
>  /* rs6000.h gets this wrong for FreeBSD.  We use the GCC defaults instead.  
> */
>  #undef WCHAR_TYPE
> -#defineWCHAR_TYPE  (TARGET_64BIT ? "int" : "long int")
> +#defineWCHAR_TYPE  "int"
>  #undef  WCHAR_TYPE_SIZE
>  #define WCHAR_TYPE_SIZE 32
>  


I can report that a make buildworld with the following WITH/WITHOUT src.conf 
type options competed based on the rebuilt powerpc64-gcc. (WITHOUT_CLANG= and 
WITHOUT_LLDB= were just to save time. The context is already libc++ based and 
so

More static link questions

2015-12-09 Thread William A. Mahaffey III




I am still having issues statically linking some inhouse code. I (tried 
to) (re)arrange the linker args in my Makefile to link what can be 
statically-linked statically & the rest dynamically, see below.



.
.
.

chmod: /usr/local/bin/PreBFCGL.opteron.TEST.static: No such file or 
directory

*** [/usr/local/bin/PreBFCGL.opteron.TEST.static] Error code 1 (ignored)
ar xv 
/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron/libmaiPre.a 
Main.o

x - Main.o
gcc5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static 
-Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
-L/home/wam/V8/Cnx/test/junk/cart/unstaggered
/bfc/pre/../lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif 
-Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre 
-lftnO2 -lBC_Phi -license
-Wl,--end-group -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm 
-lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -static-libgcc -lstdc++ 
-static-libstdc++ -Bs

tatic -lgfortran -static-libgfortran && \rm -f Main.o
chmod -fv go+rx,a-w /usr/local/bin/PreBFCGL.opteron.TEST.static
/usr/local/bin/PreBFCGL.opteron.TEST.static
Done with /usr/local/bin/PreBFCGL.opteron.TEST.static.

.
.
.

From the compile box:


[wam@devbox, pre, 10:05:02am] 4226 % uname -a
FreeBSD devbox 9.3-RELEASE-p30 FreeBSD 9.3-RELEASE-p30 #0: Mon Nov 2 
10:11:50 UTC 2015 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

[wam@devbox, pre, 10:05:05am] 4227 %


However, when I copy the statically linked executables over to another 
FreeBSD 9.3R box (this one, as it happens) & try to run it, I get the 
following:



[wam@kabini1, ~, 9:51:46am] 906 % ll -tr LIST /usr/local/bin/[B,P]* 
/usr/local/bin/*WAM* /usr/local/bin/*et*en* ; ps -Taux ; uname -a ; 
/sbin/hwclock -r ; date
lrwxr-xr-x  1 root  wheel20 Aug 27  2014 
/usr/local/bin/PreBFCGL.TEST@ -> PreBFCGL.TEST.static
lrwxr-xr-x  1 root  wheel23 Aug 27  2014 
/usr/local/bin/PreBFCGL.TEST.R8@ -> PreBFCGL.TEST.static.R8

-r-xr-xr-x  1 root  wheel 15071 Mar 18  2015 /usr/local/bin/POST*
-rw---  1 wam   users   437 Jul 11 23:13 LIST
-r-xr-xr-x  1 wam   wheel  11197960 Aug  7 05:40 
/usr/local/bin/PreBFCGL.SSE4.1.TEST.static*
-r-xr-xr-x  1 wam   wheel  11211944 Aug  7 05:40 
/usr/local/bin/PreBFCGL.SSE4.1.TEST.static.R8*
-r-xr-xr-x  1 root  wheel   420 Aug 20 13:15 
/usr/local/bin/rarian-sk-get-extended-content-list*
-r-xr-xr-x  1 root  wheel   400 Aug 20 13:15 
/usr/local/bin/rarian-sk-get-content-list*
lrwxr-xr-x  1 root  wheel35 Aug 20 13:15 
/usr/local/bin/scrollkeeper-get-extended-content-list@ -> 
rarian-sk-get-extended-content-list
lrwxr-xr-x  1 root  wheel26 Aug 20 13:15 
/usr/local/bin/scrollkeeper-get-content-list@ -> rarian-sk-get-content-list
-r-xr-xr-x  1 root  wheel  2299 Oct 10 22:20 
/usr/local/bin/pamstretch-gen*
-r-x--  1 wam   wheel   4140184 Dec  7 07:39 
/usr/local/bin/BFC.opteron.TEST.static.R8*
-r-x--  1 wam   wheel   4038096 Dec  7 07:39 
/usr/local/bin/BFC.opteron.TEST.static.R4*
-r-x--  1 wam   wheel   4033688 Dec  7 07:39 
/usr/local/bin/BFC.bdver1.TEST.static.R8*
-r-x--  1 wam   wheel   4047376 Dec  7 07:39 
/usr/local/bin/BFC.bdver1.TEST.static.R4*
lrwxr-xr-x  1 root  wheel30 Dec  7 07:39 
/usr/local/bin/PreBFCGL.TEST.static.R8@ -> PreBFCGL.bdver1.TEST.static.R8
lrwxr-xr-x  1 root  wheel27 Dec  7 07:39 
/usr/local/bin/PreBFCGL.TEST.static@ -> PreBFCGL.bdver1.TEST.static
-r-xr-xr-x  1 wam   wheel   6472832 Dec  9 09:50 
/usr/local/bin/PreBFCGL.opteron.TEST.static.R8*
-r-xr-xr-x  1 wam   wheel   6500736 Dec  9 09:50 
/usr/local/bin/PreBFCGL.opteron.TEST.static*
-r-xr-xr-x  1 wam   wheel   6574464 Dec  9 09:50 
/usr/local/bin/PreBFCGL.barcelona.TEST.static*
-r-xr-xr-x  1 wam   wheel   6518848 Dec  9 09:50 
/usr/local/bin/PreBFCGL.barcelona.TEST.static.R8*
-r-xr-xr-x  1 wam   wheel   6422688 Dec  9 09:50 
/usr/local/bin/PreBFCGL.bdver1.TEST.static.R8*
-r-xr-xr-x  1 wam   wheel   6488448 Dec  9 09:50 
/usr/local/bin/PreBFCGL.bdver1.TEST.static*

USER   PID %CPU %MEM   VSZ   RSS TT  STAT STARTEDTIME COMMAND
wam  73608  0.0  0.0 16304  2168 32  R+   10:03AM 0:00.00 ps -Taux
wam  81998  0.0  0.1 91408 20712 32  S 1Nov15 0:45.31 xterm -sl 5000 
-maximized -rv

wam  95269  0.0  0.0 18616  4288 32  Ss   12Oct15 0:02.51 tcsh
FreeBSD kabini1.local 9.3-RELEASE-p24 FreeBSD 9.3-RELEASE-p24 #0: Sat 
Aug 22 01:54:44 UTC 2015 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

/sbin/hwclock: Command not found.
Wed Dec  9 10:03:28 MCST 2015
[wam@kabini1, ~, 10:03:28am] 907 % PreBFCGL.TEST
/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by 
/usr/local/bin/PreBFCGL.TEST not found

[wam@kabini1, ~, 10:03:30am] 908 % PreBFCGL.TEST.static
/usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 required by 
/usr/local/bin/PreBFCGL.TEST.static not found

[wam@kabini1, ~, 10:03:55am] 909 % PreBFCGL.bdver1.TEST.static

Re: ongoing link issues

2015-12-09 Thread Dimitry Andric

On 09 Dec 2015, at 17:50, William A. Mahaffey III  wrote:
> 
> I am still trying to statically link my inhouse code. I switched to using 
> g++5 in the link line:
...
> g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static 
> -Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
> -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron 
> -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre 
> -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license 
> -Wl,--end-group -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt 
> -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -static-libgcc -static-libstdc++ 
> -Bstatic -lgfortran -static-libgfortran && \rm -f Main.o

> [wam@kabini1, ~, 10:51:48am] 917 % PreBFCGL.TEST
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> [wam@kabini1, ~, 10:51:52am] 918 % PreBFCGL.TEST.static
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> [wam@kabini1, ~, 10:52:02am] 919 % PreBFCGL.bdver1.TEST.static
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> [wam@kabini1, ~, 10:52:04am] 920 % uname -a

Instead of all the complicated stuff above, can't you simply use -static
while linking?  I'm not sure why you want a half-dynamic, half-static
executable?

If you want to link *some* of the libraries statically, you must enclose
these in a -Wl,-Bstatic ... -Wl,-Bdynamic pair.  For example:

-Wl,-Bstatic -lstdc++ -lgfortran -lgcc -Wl,-Bdynamic

Also, you should probably link using gcc5 instead of g++5, otherwise the
latter might add its own -lstdc++ arguments.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ongoing link issues

2015-12-09 Thread William A. Mahaffey III


On 12/09/15 12:03, Dimitry Andric wrote:

On 09 Dec 2015, at 17:50, William A. Mahaffey III  wrote:

I am still trying to statically link my inhouse code. I switched to using g++5 
in the link line:

...

g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static 
-Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
-L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron 
-L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx 
-lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO -lMotif 
-lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz 
-lm -static-libgcc -static-libstdc++ -Bstatic -lgfortran -static-libgfortran && 
\rm -f Main.o
[wam@kabini1, ~, 10:51:48am] 917 % PreBFCGL.TEST
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
[wam@kabini1, ~, 10:51:52am] 918 % PreBFCGL.TEST.static
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
[wam@kabini1, ~, 10:52:02am] 919 % PreBFCGL.bdver1.TEST.static
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
[wam@kabini1, ~, 10:52:04am] 920 % uname -a

Instead of all the complicated stuff above, can't you simply use -static
while linking?  I'm not sure why you want a half-dynamic, half-static
executable?

If you want to link *some* of the libraries statically, you must enclose
these in a -Wl,-Bstatic ... -Wl,-Bdynamic pair.  For example:

-Wl,-Bstatic -lstdc++ -lgfortran -lgcc -Wl,-Bdynamic

Also, you should probably link using gcc5 instead of g++5, otherwise the
latter might add its own -lstdc++ arguments.

-Dimitry



I went ahead & tried the -Wl,-Bstatic & -Wl,-Bdynamic (I show output 
from successful dynamic link & problematic static link for comparison):


.
.
.

chmod: /usr/local/bin/PreBFCGL.opteron.TEST.R8: No such file or directory
*** [/usr/local/bin/PreBFCGL.opteron.TEST.R8] Error code 1 (ignored)
ar xv 
/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R8/opteron/libmaiPre.a 
Main.o

x - Main.o
g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.R8 
-Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
-L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc
/pre/../lib/R8/opteron -L/home/wam/lib/R8  -L/usr/lib64/openmotif 
-L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron 
-L/home/wam/lib/R4  -L/usr/l
ib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils 
-lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO 
-lMotif -lStdHash -lgfortran -l
gomp -lgcc -lmpi -ltet -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg 
-lpng -lz -lm && \rm -f Main.o

chmod -fv go+rx,a-w /usr/local/bin/PreBFCGL.opteron.TEST.R8
/usr/local/bin/PreBFCGL.opteron.TEST.R8
Done with /usr/local/bin/PreBFCGL.opteron.TEST.R8.
MakePRE: Everything usual up to Date.
Everything MemLibs up to date.
Everything HashLibs up to date.
Everything DumpLibs up to date.
Everything BCLibs up to date.
Everything allLibs up to date.
chmod: /usr/local/bin/PreBFCGL.opteron.TEST.static: No such file or 
directory

*** [/usr/local/bin/PreBFCGL.opteron.TEST.static] Error code 1 (ignored)
ar xv 
/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron/libmaiPre.a 
Main.o

x - Main.o
g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static 
-Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
-L/home/wam/V8/Cnx/test/junk/cart/unstaggered
/bfc/pre/../lib/R4/opteron -L/home/wam/lib/R4 -L/usr/lib64/openmotif 
-Wl,--start-group -lmaiPre -lPre -lPrecxx -lutils -lftndmp -lftnO2pre 
-lftnO2 -lBC_Phi -license
-Wl,--end-group -lMemIO -lMotif -lStdHash -static-libstdc++ -Wl,-Bstatic 
-lgfortran -lgomp -lgcc -Wl,-Bdynamic -lmpi -ltet -lMrm -lXm -lXt -lGL 
-lGLU -lGLw -lX11 -ljp

eg -lpng -lz -lm && \rm -f Main.o
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.a(write.o): 
In function `write_float':
/usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1306: 
undefined reference to `sig

nbitq'
/usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1306: 
undefined reference to `fin

iteq'
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.a(write.o): 
In function `determine_en_precision':
/usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1213: 
undefined reference to `fin

iteq'
/usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd9.3/5.2.1/../../../libgfortran.a(write.o): 
In function `write_float':
/usr/ports/lang/gcc5-devel/work/build/x86_64-portbld-freebsd9.3/libgfortran/../.././../gcc-5-20151124/libgfortran/io/write_float.def:1306: 
undefined reference to `isn

anq'

Re: ongoing link issues

2015-12-09 Thread William A. Mahaffey III


On 12/09/15 12:03, Dimitry Andric wrote:

On 09 Dec 2015, at 17:50, William A. Mahaffey III  wrote:

I am still trying to statically link my inhouse code. I switched to using g++5 
in the link line:

...

g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static 
-Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
-L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron 
-L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre -lPrecxx 
-lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license -Wl,--end-group -lMemIO -lMotif 
-lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz 
-lm -static-libgcc -static-libstdc++ -Bstatic -lgfortran -static-libgfortran && 
\rm -f Main.o
[wam@kabini1, ~, 10:51:48am] 917 % PreBFCGL.TEST
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
[wam@kabini1, ~, 10:51:52am] 918 % PreBFCGL.TEST.static
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
[wam@kabini1, ~, 10:52:02am] 919 % PreBFCGL.bdver1.TEST.static
/lib/libgcc_s.so.1: version GCC_4.6.0 required by 
/usr/local/lib/gcc48/libgfortran.so.3 not found
[wam@kabini1, ~, 10:52:04am] 920 % uname -a

Instead of all the complicated stuff above, can't you simply use -static
while linking?  I'm not sure why you want a half-dynamic, half-static
executable?

If you want to link *some* of the libraries statically, you must enclose
these in a -Wl,-Bstatic ... -Wl,-Bdynamic pair.  For example:

-Wl,-Bstatic -lstdc++ -lgfortran -lgcc -Wl,-Bdynamic

Also, you should probably link using gcc5 instead of g++5, otherwise the
latter might add its own -lstdc++ arguments.

-Dimitry



Thanks for your reply. I tried '-static' earlier (see posts last week) & 
the linker couldn't find static libraries for LibGL, libGLU & libGLw.



I also tried gcc5 to link (see earlier posts today) & it seemed to still 
dynamically link libstdc++, even w/ the '-static-libstdc++' argument. 
Your suggestion to use the explicit linker arguments -Bstatic & 
-Bdynamic is the next thing to try, however they will require a bit more 
mods to my Makefile & I thought my attempts using various 
'-static-lib' should/would work, based on my read of the man 
pages.



--

William A. Mahaffey III

 --

"The M1 Garand is without doubt the finest implement of war
 ever devised by man."
   -- Gen. George S. Patton Jr.

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: powerpc64-gcc 5.2 vintages get L". . ." type wrong compared to Char for FreeBSD for lib32 compiling

More static link questions

Re: ongoing link issues

Re: ongoing link issues

Re: ongoing link issues

5 matches

Site Navigation

Mail list logo

Footer information