Re: fun with libtool for masochistic guys
Okay, current decision is to actually pass options we do not understand to cc, and to look harder at options. So far, this is actually finding problems in ports. Stuff that would be completely ignored, or miscompiled. Check ports-changes@ for details.
Re: fun with libtool for masochistic guys
On Thu, Jul 12, 2012 at 12:33:18AM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 11:24:37PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 03:13:19PM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 01:08:43PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg Is that a joke ? 'cause I can't tell. Nope, I'm pretty serious. Sure enough, either behavior sucks... You should get your priorities straight ! occasionnally, gcc behavior can be a bit annoying, but it's never ever a silent bug ! There is a difference e.g. between using -static and -Wl,-static. Depending on which combination of gcc and ld you are using, that can result in pretty obnoxious bugs too. Joerg
fun with libtool for masochistic guys
Lots of fun last night and this morning. 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. Case in point: libdns/ldns. It does link with libtool link cc -o somelib --export-symbols lib.def someobj.o notice the --export-symbols, that's not a valid gnu libtool option (the option is spelled -export-symbols). So it gets ignored ! this did work by accident for us, since we used Getopt::Long which doesn't care if it's --export-symbols or -export-symbols... when I fixed that, suddenly, we got some different behavior, so our link stopped working. But I'll contend that's a fucking BUG in gnu libtool, since you can just mispell something, and hey, watch it ! magic trick! it's gone !!! (that also explains why some ports require gnu libtool... linking with libtool link cc -o prog a.o a.c will work with gnu libtool... yeah, I kid you not !) 2/ we had some bugs with variable mispelling for weeks... turns out some stuff to check for standard library paths was totally broken. So I fixed it, and so it broke libtool, because there's some other bug that means that we don't look where we should. More precisely -L/usr/X11/lib -lX11 will bring in -lxcb... and that's it ! but -lxcb *in turn* needs to bring in pthread-stubs Xau and Xdmcp All live under /usr/X11R6/lib... and the linker complains. So I fixed that by adding -rpath-link for standard directories, and -rpath for non-standard directories... The deeper bug being that we do not look inside xcb for further paths, which is probably what needs to happen. Well, at least libtool builds should no longer include rpaths for /usr/local/lib and /usr/X11R6/lib...
Re: fun with libtool for masochistic guys
On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg
Re: fun with libtool for masochistic guys
On Wed, Jul 11, 2012 at 01:08:43PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg Is that a joke ? 'cause I can't tell.
Re: fun with libtool for masochistic guys
On Jul 11 10:57:21, Marc Espie wrote: Lots of fun last night and this morning. 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. Case in point: libdns/ldns. It does link with libtool link cc -o somelib --export-symbols lib.def someobj.o notice the --export-symbols, that's not a valid gnu libtool option (the option is spelled -export-symbols). So it gets ignored ! this did work by accident for us, since we used Getopt::Long which doesn't care if it's --export-symbols or -export-symbols... when I fixed that, suddenly, we got some different behavior, so our link stopped working. But I'll contend that's a fucking BUG in gnu libtool, since you can just mispell something, and hey, watch it ! magic trick! it's gone !!! (that also explains why some ports require gnu libtool... Marc, could you please confirm that this is why audio/opencore-amr builds with USE_LIBTOOL=gnu but not otherwise? With USE_LIBTOOL=yes, the linking fails with libtool: link: cc -shared -fPIC -DPIC -o .libs/libopencore-amrnb.so.0.0 -I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/oscl -I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/au dio/gsm_amr/amr_nb/dec/src -I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/au dio/gsm_amr/amr_nb/common/include -I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/au dio/gsm_amr/amr_nb/dec/include -I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/au dio/gsm_amr/common/dec/include -I/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1.3/opencore/codecs_v2/au dio/gsm_amr/amr_nb/enc/src -x c -std=c99 -O2 -pipe .libs/wrapper.o .libs/agc.o .libs/amrdecode.o .libs/a_refl.o .libs/b_cn_cod.o .libs/bgnscd.o .libs/c_g_aver.o .libs/d1035pf.o .libs/d2_11pf.o .libs/d2_9pf.o .libs/d3_14pf.o .libs/d4_17pf.o .libs/d8_31pf.o .libs/dec_amr.o .libs/dec_gain.o .libs/dec_input_format_tab.o .libs/dec_lag3.o .libs/dec_lag6.o .libs/d_gain_c.o .libs/d_gain_p.o .libs/d_plsf_3.o .libs/d_plsf_5.o .libs/d_plsf.o .libs/dtx_dec.o .libs/ec_gains.o .libs/ex_ctrl.o .libs/if2_to_ets.o .libs/int_lsf.o .libs/lsp_avg.o .libs/ph_disp.o .libs/post_pro.o .libs/preemph.o .libs/pstfilt.o .libs/qgain475_tab.o .libs/sp_dec.o .libs/wmf_to_ets.o .libs/amrencode.o .libs/autocorr.o .libs/c1035pf.o .libs/c2_11pf.o .libs/c2_9pf.o .libs/c3_14pf.o .libs/c4_17pf.o .libs/c8_31pf.o .libs/calc_cor.o .libs/calc_en.o .libs/cbsearch.o .libs/cl_ltp.o .libs/cod_amr.o .libs/convolve.o .libs/cor_h.o .libs/cor_h_x2.o .libs/cor_h_x.o .libs/corrwght_tab.o .libs/div_32.o .libs/dtx_enc.o .libs/enc_lag3.o .libs/enc_lag6.o .libs/enc_output_format_tab.o .libs/ets_to_if2.o .libs/ets_to_wmf.o .libs/g_adapt.o .libs/gain_q.o .libs/g_code.o .libs/g_pitch.o .libs/hp_max.o .libs/inter_36.o .libs/inter_36_tab.o .libs/l_abs.o .libs/lag_wind.o .libs/lag_wind_tab.o .libs/l_comp.o .libs/levinson.o .libs/l_extract.o .libs/lflg_upd.o .libs/l_negate.o .libs/lpc.o .libs/ol_ltp.o .libs/pitch_fr.o .libs/pitch_ol.o .libs/p_ol_wgh.o .libs/pre_big.o .libs/pre_proc.o .libs/prm2bits.o .libs/qgain475.o .libs/qgain795.o .libs/q_gain_c.o .libs/q_gain_p.o .libs/qua_gain.o .libs/s10_8pf.o .libs/set_sign.o .libs/sid_sync.o .libs/sp_enc.o .libs/spreproc.o .libs/spstproc.o .libs/ton_stab.o .libs/vad1.o .libs/add.o .libs/az_lsp.o .libs/bitno_tab.o .libs/bitreorder_tab.o .libs/c2_9pf_tab.o .libs/div_s.o .libs/extract_h.o .libs/extract_l.o .libs/gains_tbl.o .libs/gc_pred.o .libs/get_const_tbls.o .libs/gmed_n.o .libs/gray_tbl.o .libs/grid_tbl.o .libs/int_lpc.o .libs/inv_sqrt.o .libs/inv_sqrt_tbl.o .libs/l_deposit_h.o .libs/l_deposit_l.o .libs/log2.o .libs/log2_norm.o .libs/log2_tbl.o .libs/lsfwt.o .libs/l_shr_r.o .libs/lsp_az.o .libs/lsp.o .libs/lsp_lsf.o .libs/lsp_lsf_tbl.o .libs/lsp_tab.o .libs/mult_r.o .libs/negate.o .libs/norm_l.o .libs/norm_s.o .libs/overflow_tbl.o .libs/ph_disp_tab.o .libs/pow2.o .libs/pow2_tbl.o .libs/pred_lt.o .libs/q_plsf_3.o .libs/q_plsf_3_tbl.o .libs/q_plsf_5.o .libs/q_plsf_5_tbl.o .libs/q_plsf.o .libs/qua_gain_tbl.o .libs/reorder.o .libs/residu.o .libs/round.o .libs/set_zero.o .libs/shr.o .libs/shr_r.o .libs/sqrt_l.o .libs/sqrt_l_tbl.o .libs/sub.o .libs/syn_filt.o .libs/weight_a.o .libs/window_tab.o -L.libs -lm -Wl,-retain-symbols-file,/usr/ports/pobj/opencore-amr-0.1.3/opencore-amr-0.1. 3/amrnb/opencore-amrnb.sym .libs/wrapper.o:1: error: stray '\177' in program .libs/wrapper.o:1: error: stray '\1' in program .libs/wrapper.o:1: error: stray '\2' in program .libs/wrapper.o:1: error: stray '\1' in program [...] Note the -x c ... file.o; it treats the *.o files as C source and fails. (Which itself is probably a bug in the non-gnu libtool, right?) With USE_LIBTOOL=gnu, the linking line becomes libtool: link: cc -shared -fPIC -DPIC -o .libs/libopencore-amrnb.so.0.0 .libs/wrapper.o .libs/agc.o .libs/amrdecode.o .libs/a_refl.o .libs/b_cn_cod.o .libs/bgnscd.o .libs/c_g_aver.o .libs/d1035pf.o .libs/d2_11pf.o .libs/d2_9pf.o
Re: fun with libtool for masochistic guys
On Wed, Jul 11, 2012 at 03:13:19PM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 01:08:43PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg Is that a joke ? 'cause I can't tell. Nope, I'm pretty serious. Sure enough, either behavior sucks... Joerg
Re: fun with libtool for masochistic guys
On Wed, Jul 11, 2012 at 11:24:37PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 03:13:19PM +0200, Marc Espie wrote: On Wed, Jul 11, 2012 at 01:08:43PM +0200, Joerg Sonnenberger wrote: On Wed, Jul 11, 2012 at 10:57:21AM +0200, Marc Espie wrote: 1/ Turns out GNU libtool simply *removes* stuff it doesn't understand while linking. I find that no more buggy than GCC passing all unknown junk to ld... Joerg Is that a joke ? 'cause I can't tell. Nope, I'm pretty serious. Sure enough, either behavior sucks... You should get your priorities straight ! occasionnally, gcc behavior can be a bit annoying, but it's never ever a silent bug ! I've found at least one instance where libtool ignores some mispelled option entirely.. What do you think of a link line that would read libtool --mode=link cc -o a --hey-im-dog --and-i-have-no-fucking-idea-what-im-doing a.lo guess what ? that *will work with gnu libtool* because it just fucking completely discards what it doesn't understand. That's fucking dangerous ! it means that, if you have an option that helps you making better executable, like say a -fstack-protector like option that would run during linking, you can't just say CC='cc -fmy-magic-option' and hope that libtool link will actually use it. That's totally sick and completely stupid. there's no way in hell we're going to emulate such wacky bogus insecure behavior !
