search for: muldefs

...someone has an issue with > > > > the new proposed -pre, they can try -pre2 with minimal differences to > > > > separate a gnu-efi related issue from others. > > > > > > NP, but I would fix the link problem with gnu-efi >= 3.0.8 first, just adding a -z muldefs > > > will work for all versions I think. > > > > > > > -z muldefs would bloat the libraries unnecessarily, but worse it might > > mask real errors. > > Looking into the debian patches posted here I see that not using -z muldefs causes > bugs. I think...

...took such a large leap? My thought is if someone has an issue with >> the new proposed -pre, they can try -pre2 with minimal differences to >> separate a gnu-efi related issue from others. > > NP, but I would fix the link problem with gnu-efi >= 3.0.8 first, just adding a -z muldefs > will work for all versions I think. > -z muldefs would bloat the libraries unnecessarily, but worse it might mask real errors. There is a good reason we snapshot gnu-efi as opposed to using whatever version the user has... -hpa

...I merged your tree and added the install patch on top of it. Thank you! Great, that tree now against a somewhat old gnu-efi though. To build against >= 3.0.8 I need to do: #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" Jocke

...wrote: > > > > Great, that tree now against a somewhat old gnu-efi though. > > > > To build against >= 3.0.8 I need to do: > > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > > sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" > > > > Should be a trivial fix by simply omitting those from the > syslinux-provided library functions on EFI. Yes, but I don't know the code that well so I took the easy way :) Also, syslinux overides/omits xFLAGS(CFLAG...

...p? My thought is if someone has an issue with > > > the new proposed -pre, they can try -pre2 with minimal differences to > > > separate a gnu-efi related issue from others. > > > > NP, but I would fix the link problem with gnu-efi >= 3.0.8 first, just adding a -z muldefs > > will work for all versions I think. > > > > -z muldefs would bloat the libraries unnecessarily, but worse it might > mask real errors. Looking into the debian patches posted here I see that not using -z muldefs causes bugs. I think you should just use muldefs and report...

On 2/7/19 1:53 PM, Joakim Tjernlund wrote: \>>> >>> -z muldefs would bloat the libraries unnecessarily, but worse it might >>> mask real errors. >> >> Looking into the debian patches posted here I see that not using -z muldefs causes >> bugs. I think you should just use muldefs and report the duplicated memset/memcpy syms >> in...

...Anvin wrote: > > > > Great, that tree now against a somewhat old gnu-efi though. > > > > To build against >= 3.0.8 I need to do: > > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > > sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" > > > > Should be a trivial fix by simply omitting those from the > syslinux-provided library functions on EFI. > > -hpa > All this has been already done in Debian Testing a couple of months ago (at least). The ne...

...800, H. Peter Anvin wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > On 2/7/19 1:53 PM, Joakim Tjernlund wrote: > \>>> > > > > -z muldefs would bloat the libraries unnecessarily, but worse it might > > > > mask real errors. > > > > > > Looking into the debian patches posted here I see that not using -z muldefs causes > > > bugs. I think you should just use muldefs and report the duplicated mems...

?Asterisk 13.11 rc1 ./configure LDFLAGS="-z muldefs" --libdir=/usr/lib64 --with-unixodbc=$(odbc_config --include-prefix)/ --disable-dev-mode --with-pjproject-bundled ?checking for pjsip_dlg_create_uas_and_inc_lock in -lpjsip... no checking for pjsip_tsx_create_uac2 in -lpjsip... no checking if "pjmedia_mod_offer_flag flag = PJMEDIA_SDP_NE...

On Wed, Feb 6, 2019 at 2:35 PM H. Peter Anvin via Syslinux <syslinux at zytor.com> wrote: > > On 2/6/19 9:17 AM, Joakim Tjernlund via Syslinux wrote: > > On Wed, 2019-02-06 at 16:00 +0100, Joakim Tjernlund wrote: > >> On Tue, 2019-02-05 at 14:07 -0800, H. Peter Anvin via Syslinux wrote: > >>> CAUTION: This email originated from outside of the organization. Do

...2-06 at 11:34 -0800, H. Peter Anvin wrote: > > Great, that tree now against a somewhat old gnu-efi though. > > To build against >= 3.0.8 I need to do: > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" > Should be a trivial fix by simply omitting those from the syslinux-provided library functions on EFI. -hpa

...> > Great, that tree now against a somewhat old gnu-efi though. > > > > > > To build against >= 3.0.8 I need to do: > > > #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors > > > sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" > > > > > > > Should be a trivial fix by simply omitting those from the > > syslinux-provided library functions on EFI. > > > > -hpa > > > > All this has been already done in Debian...

...> >>> Great, that tree now against a somewhat old gnu-efi though. >>> >>> To build against >= 3.0.8 I need to do: >>> #gnu-efi >= 3.0.8 has memset/memcpy defined causing multiple syms errors >>> sed -i 's/LDFLAGS =/LDFLAGS = -z muldefs /' mk/efi.mk || die "sed muldefs failed" >>> >> >> Should be a trivial fix by simply omitting those from the >> syslinux-provided library functions on EFI. > > Yes, but I don't know the code that well so I took the easy way :) > > Also, sys...

I think I botched syslinux-6.04-pre3. There are two fundamental problems with the build: a) The selection of what pieces of the library gets included in the core is done manually whereas it really should be automatic; b) The build doesn't fail if there are unresolved dependencies between the libraries and the core. I will fix these. (b) is IMO fundamental to avoid this error in the

...doesn't fail if there are unresolved dependencies >between >> the libraries and the core. >> >> I will fix these. (b) is IMO fundamental to avoid this error in the >> future, so I want to fix it correctly. >> >> -hpa > >I think using -z muldefs when linking against gnu-efi(vs. excluding >memcpy/memset) would be beneficial. >That way building syslinux against older/future gnu-efi will not break >and you get your >optimized memset/memcpy impl. Gnu-efi just has the simplest impl. of >these functions. > > Jocke No. It re...

I'm working with a C++ code generator that produces multiple instances of the same definition (specifically, it generates explicit instantiations of the same template in multiple output source files). With the GNU ld, I'm able to link successfully using the --allow-multiple-definitions flag; however this flag is not supported in llvm-ld. Is there any way I can either convince llvm-ld to

On Wed, 2019-02-06 at 16:00 +0100, Joakim Tjernlund wrote: > On Tue, 2019-02-05 at 14:07 -0800, H. Peter Anvin via Syslinux wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > Hi all, > > > > It has been the case for

Jan, maybe I should check the /afs information that you pointed me at in a subsequent email first, but I wanted to update you on what happened following this path: I did get some mileage out of both of your suggestions below, but still did not make it through (now working with openssh-2.9p2): gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o readconf.o clientloop.o -L.

Hello, Jay > I don't know what libstdc++'s stubs.o is for. If I create a bodged > version of libstdc++ that doesn't include stubs.o, then llc links > successfully! > > I've tried coming up with a small C++ app that gives the same linker > error, but so far without success. Sounds like broken compiler and/or mingw runtime. This perfectly explains, why mingw gcc

>> I don't know what libstdc++'s stubs.o is for. If I create a bodged >> version of libstdc++ that doesn't include stubs.o, then llc links >> successfully! >> >> I've tried coming up with a small C++ app that gives the same linker >> error, but so far without success. > Sounds like broken compiler and/or mingw runtime. This perfectly >