Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On Wed, 19 Jul 2017 22:50:04 +0200 (CEST) Gerald Pfeifer wrote: > On Fri, 14 Apr 2017, Alexander Kabaev wrote: > > it was suggested multiple times that the whole fixinc step is > > ultimately harmful and serves no useful purpose and probably should > > be disabled in built packages outright. Is there a reason not to do > > it? Even Redhat appears to do the slimming in their rpms: > > For the more current lang/gcc* ports (not the gcc5-aux and gcc6-aux > ports which I do not maintain) I have now removed packaging the > headers processed by fixincludes, so any problems in that direction > should be gone. > > Gerald Thank you, Gerald! -- Alexander Kabaev pgpxzoBOngxmA.pgp Description: Цифровая подпись OpenPGP
Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)
On Sat, 15 Apr 2017 09:30:49 +1000 (AEST) Gerald Pfeifer wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: > > I didn't want to get into this but the problem is that as part of > > it's build/bootstrapping process, GCC historically takes system > > headers and attempts to "fix" them. I am unsure the fixes do > > anything at all nowadays but the effect is that the compiler tends > > to take snapshots of the system headers when it is built. cdefs.h > > is used by all the system headers so changes in cdefs.h have good > > chances affecting such builds but any change are likely to cause > > similar trouble. > > > > In the case of gcc-aux, it appears the compilation is based on a > > bootstrap compiler which already carries outdated headers. > > A workaround, suggested by gerald@ the last time a similar issue > > happened was to run for install-tools/fixinc.sh. I think that may > > regenerate the headers and let the build use updated headers. > > Ultimately gcc-aux needs maintainer intervention and using > > outdated headers will break sooner or later: especially on > > -current. > > Indeed, thanks for the analysis/background, Pedro! > > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, > and perhaps John (as the maintainer of that port) has plans to update > it? Let me copy him. > > Gerald > > PS: John, if you have an update, happy to help and apply that for you. Hi Gerald, it was suggested multiple times that the whole fixinc step is ultimately harmful and serves no useful purpose and probably should be disabled in built packages outright. Is there a reason not to do it? Even Redhat appears to do the slimming in their rpms: mv $FULLPATH/include-fixed/syslimits.h $FULLPATH/include/syslimits.h mv $FULLPATH/include-fixed/limits.h $FULLPATH/include/limits.h for h in `find $FULLPATH/include -name \*.h`; do if grep -q 'It has been auto-edited by fixincludes from' $h; then rh=`grep -A2 'It has been auto-edited by fixincludes from' $h | tail -1 | sed 's|^.*"\(.*\)".*$|\1|'` diff -up $rh $h || : rm -f $h fi done -- Alexander Kabaev pgpzeAwZ9onkU.pgp Description: Цифровая подпись OpenPGP
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Thu, 23 Aug 2012 18:19:57 -0400 Steve Wills wrote: > Hi, > > It seems to me that renaming the pkg binary in /usr/sbin/pkg > to /usr/sbin/pkg-bootstrap would make sense. From a user standpoint, > it is confusing that running the command gets different results the > second time it is run vs. the first time. I can imagine a user saying > "I ran pkg, but it didn't do what they said it would. Now I run it > again, and it does do what it is supposed to." Also, it would enable > setting up a pkg-bootstrap man page separate from the pkg man page, > without confusion about which one you're looking at. > > So, opinions? There may still be time to fix it for 9.1 if we can > decide quickly. > > Thanks, > Steve > Remove it or rename it. Do _NOT_ make it download the package and install it silently as this is a security nightmare waiting to happen. -- Alexander Kabaev signature.asc Description: PGP signature
Re: __FreeBSD_version bump? (was: Re: vlc 2.0.3 ProjectM path fix)
On Mon, 20 Aug 2012 13:15:10 +0300
Konstantin Belousov wrote:
> On Sat, Aug 18, 2012 at 10:45:10PM +0200, Juergen Lock wrote:
> > On Wed, Aug 15, 2012 at 10:09:59AM -0700, Kevin Oberman wrote:
> > > On Wed, Aug 15, 2012 at 5:01 AM, Juergen Lock
> > > wrote:
> > > > On Tue, Aug 14, 2012 at 09:54:54PM +0200, Olli Hauer wrote:
> > > >> ...
> > > >> >> I think I got it: It is only a problem of configuring in
> > > >> >> the running vlc. You have to set the right path under
> > > >> >> 'Settings','All','Audio','Visualizing','projectM'. That's
> > > >> >> all ;-)
> > > >> >>
> > > >> > Aah-haah! :) I've fixed the default paths and made a new
> > > >> > patch:
> > > >> >
> > > >> > http://people.freebsd.org/~nox/tmp/vlc-2.0.3-010.patch
> > > >> >
> > > >>
> > > >>
> > > >> >From your patch:
> > > >> > workaround is to deinstall the old vlc-1.x version before
> > > >> > building the new one.
> > > >>
> > > >> What about a conflict line ?
> > > >> CONFLICTS_BUILD=${PORTNAME}-1.*
> > > >>
> > > >> This allows users to fetch the source but they have to
> > > >> deinstall the old version before building the new one.
> > > >
> > > > Hm well the rtld bug this workaround is for only affects the
> > > > pulseaudio and notify knobs, and the workaround doesn't work for
> > > > the notify knob so it would only cover half the cases, and also
> > > > checking if this is needed in the port would require a
> > > > __FreeBSD_version bump which is probably overkill for this bug.
> > >
> > > And why is it overkill? I regularly see comments about not
> > > wanting to bump __FreeBSD_version, but it's just an integer
> > > (though presented as a fixed-point fraction). There is no
> > > shortage and I never have understood why people are so hesitant
> > > to change it when there is a real, even if fairly small benefit
> > > from the bump.
> >
> > Hmm. Alexander, what do you think?
>
> Not being Alexander, but appeared on Cc:.
>
> IMO, bumping __FreeBSD_version should not be done frivolous, and
> routine bug fixes are definitely not the good reason to bump.
>
> For one, users of HEAD or stable are assumed to run tip of the branch.
> If you want defined point of the branch, use release. With this POV,
> the usefulness of the bump for bug fix is only a week or two.
>
> Second, bump of __FreeBSD_version signifies major incompatibility
> between pre-bumped tree and current one. In the kernel, each bump of
> version in HEAD means that new modules cannot be loaded into new
> kernel.
>
> Bumping for bug fixes is a misuse of the mechanism which was put there
> to provide information about major changes in system. For small or
> detectable items, use autoconf-like runtime (or build-time *) tests.
>
> * - Usually, the tests must be run-time, and not build-time. This bug
> is greatly amplified by use of __FreeBSD_version. The case that
> initiated the discussion is probably the first time I ever saw the
> when build-time test makes some sense.
I agree with Konstantin and I do not see the point to bump the version
just to serve fleeting needs of -stable or -current branch users -
their problems will be gone with upgrade to the tip of the respective
branch and this is the first thing they are expected to do before
reporting a bug anyway.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Another vlc 2.0.3 update (new ffmpeg! :)
On Mon, 13 Aug 2012 23:52:12 +0200
Juergen Lock wrote:
> On Mon, Aug 13, 2012 at 08:12:42PM +0200, Gary Jennejohn wrote:
> > On Mon, 13 Aug 2012 02:41:35 -0400
> > Alexander Kabaev wrote:
> >
> > [snip lots of gdb trace]
> >
> > > Please check the use of _SC_GETPW_R_SIZE_MAX in vlcpulse.c. This
> > > constant is unsupported, so the module tries to allocate a stack
> > > buffer with negative size, smashing the stack dead.
> > >
> >
> > Seems like a good idea, but I replaced the rather sloppy
> > buf[sysctl(_SC_GETPW_R_SIZE_MAX)];
> > with
> > buf[2048];
> > and vlc still core dumps when trying to generate plugins.dat.
>
> Yeah that seems to be a different issue (rtld).
> Juergen
Please try this patch.
--
Alexander Kabaev
diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c
index 95358aa..6f6ac70 100644
--- a/libexec/rtld-elf/rtld.c
+++ b/libexec/rtld-elf/rtld.c
@@ -1743,6 +1743,27 @@ init_dag(Obj_Entry *root)
root->dag_inited = true;
}
+static void
+process_nodelete(Obj_Entry *root)
+{
+const Objlist_Entry *elm;
+
+/*
+ * Walk over object DAG and process every dependent object
+ * that is marked as DF_1_NODELETE. They need to grow own
+ * dag, which should then be ref-ed separately.
+ */
+STAILQ_FOREACH(elm, &root->dagmembers, link) {
+ if (elm->obj != NULL && elm->obj->z_nodelete &&
+ !elm->obj->ref_nodel) {
+ dbg("obj %s nodelete", elm->obj->path);
+ init_dag(elm->obj);
+ ref_dag(elm->obj);
+ elm->obj->ref_nodel = true;
+ }
+}
+root->dag_inited = true;
+}
/*
* Initialize the dynamic linker. The argument is the address at which
* the dynamic linker has been mapped into memory. The primary task of
@@ -1932,12 +1953,6 @@ process_needed(Obj_Entry *obj, Needed_Entry *needed, int flags)
flags & ~RTLD_LO_NOLOAD);
if (obj1 == NULL && !ld_tracing && (flags & RTLD_LO_FILTEES) == 0)
return (-1);
- if (obj1 != NULL && obj1->z_nodelete && !obj1->ref_nodel) {
- dbg("obj %s nodelete", obj1->path);
- init_dag(obj1);
- ref_dag(obj1);
- obj1->ref_nodel = true;
- }
}
return (0);
}
@@ -2833,8 +2848,12 @@ dlopen_object(const char *name, int fd, Obj_Entry *refobj, int lo_flags,
/* Make list of init functions to call. */
initlist_add_objects(obj, &obj->next, &initlist);
}
+ /*
+ * Process all no_delete objects here, given them own
+ * DAGs to prevent their dependencies from being unloaded.
+ */
+ process_nodelete(obj);
} else {
-
/*
* Bump the reference counts for objects on this DAG. If
* this is the first dlopen() call for the object that was
signature.asc
Description: PGP signature
Re: Another vlc 2.0.3 update (new ffmpeg! :)
On Mon, 13 Aug 2012 01:12:10 +0200
Juergen Lock wrote:
> On Sun, Aug 12, 2012 at 09:21:15PM +0200, Rainer Hurling wrote:
> > On 12.08.2012 19:14 (UTC+2), Rainer Hurling wrote:
> > > On 12.08.2012 19:11 (UTC+2), Juergen Lock wrote:
> >GEN../modules/plugins.dat
> > gmake[2]: *** [../modules/plugins.dat] Segmentation fault: 11
> > (Speicherauszug erstellt)
> > gmake[2]: Leaving directory
> > `/usr/ports/multimedia/vlc/work/vlc-2.0.3/bin' gmake[1]: ***
> > [all-recursive] Fehler 1 gmake[1]: Leaving directory
> > `/usr/ports/multimedia/vlc/work/vlc-2.0.3' gmake: *** [all] Fehler 2
> > *** [do-build] Error code 1
> >
> > This only happens when option PulseAudio is enabled. (My sound
> > system is driven by PulseAudio.)
> >
> Aah, thanx, I missed the bit about pulseaudio, now I can finally
> reproduce this. I'll follow up on the other thread with the bt
> kib wanted.
>
I was unable to reproduce this one at all. I _do_ have VLC 1.x
installed as well, though I have no pulseaudio enabled in it.
Maybe that is another missing piece of the puzzle?
> > And, as described in another thread on August, 3rd, it only
> > happens, when vlc version 1.x is already installed. So, deleting
> > old vlc before build this new version works for me.
> >
> > Unfortunately if option PulseAudio is enabled, and only then, vlc
> > core dumps right after opening for example mp3 or mp4 files :(
>
> Hm if I did this right the bt for that is:
>
> [...]
> Loaded symbols for /libexec/ld-elf.so.1
> #0 0x000816d33068 in vlc_pa_connect (obj=0x6f6e2f656d6f682f,
> mlp=0x6b636f4c206e65) at vlcpulse.c:137 137
> pa_threaded_mainloop_lock (mainloop); gdb) bt
> #0 0x000816d33068 in vlc_pa_connect (obj=0x6f6e2f656d6f682f,
> mlp=0x6b636f4c206e65) at vlcpulse.c:137 #1 0x000816d34682 in
> Open (obj=Variable "obj" is not available. ) at pulse.c:840
> #2 0x000800aba580 in vlc_module_load ()
> from /usr/local/lib/libvlccore.so.6 #3 0x000800aaab2c in
> aout_VolumeHardSet () from /usr/local/lib/libvlccore.so.6 #4
> 0x000800aa83c3 in aout_TimeReport ()
> from /usr/local/lib/libvlccore.so.6 #5 0x000800a75f70 in
> decoder_NewPicture () from /usr/local/lib/libvlccore.so.6 #6
> 0x0008134c77e8 in _::vlc_entry_license ()
> from /usr/local/lib/vlc/plugins/codec/libfaad_plugin.so #7
> 0x000800a76d83 in input_DecoderCreate ()
> from /usr/local/lib/libvlccore.so.6 #8 0x000800a7810d in
> input_DecoderCreate () from /usr/local/lib/libvlccore.so.6 #9
> 0x000800a785db in input_DecoderCreate ()
> from /usr/local/lib/libvlccore.so.6 #10 0x00080169c58d in
> pthread_create () from /lib/libthr.so.3 #11 0x in ??
> () Cannot access memory at address 0x7edf4000 (gdb) l
> vlcpulse.c:130 125 { 126 pa_proplist_setf
> (props, PA_PROP_APPLICATION_PROCESS_MACHINE_ID,
> 127 "%.32s", session); /* XXX: is
> this valid? */ 128 pa_proplist_sets (props,
> PA_PROP_APPLICATION_PROCESS_SESSION_ID,
> 129 session); 130 }
> 131 } 132 133 /* Connect to PulseAudio daemon */
> 134 pa_context *ctx; (gdb) l
> 135 pa_mainloop_api *api;
> 136
> 137 pa_threaded_mainloop_lock (mainloop);
> 138 api = pa_threaded_mainloop_get_api (mainloop);
> 139 ctx = pa_context_new_with_proplist (api, ua, props);
> 140 free (ua);
> 141 if (props != NULL)
> 142 pa_proplist_free (props);
> 143 if (unlikely(ctx == NULL))
> 144 goto fail;
> (gdb)
>
> I'll Cc the pulseaudio port maintainers (gnome@), maybe they have an
> idea?
>
Please check the use of _SC_GETPW_R_SIZE_MAX in vlcpulse.c. This
constant is unsupported, so the module tries to allocate a stack buffer
with negative size, smashing the stack dead.
So far, I see absolutely no evidence of any wrongdoing on the rtld
side of things.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
On Mon, 13 Aug 2012 01:13:35 +0200 Juergen Lock wrote: > On Sun, Aug 05, 2012 at 07:38:11PM +0200, Juergen Lock wrote: > > On Sun, Aug 05, 2012 at 07:13:53PM +0300, Konstantin Belousov wrote: > > > On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: > > > > Hi kib, -current, seems we have a segfault in rtld when updating > > > > the multimedia/vlc port from the version currently in ports to > > > > the 2.0.3 CFT version from here: > > > > > > > > http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch > > > > > > > > (If you test the LIVEMEDIA knob you also need this update: > > > > > > > > http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch > > > > > > > > ) > > > Please do two things. > > > > > > 1. Provide me the output of readelf -a for the module that was > > > loaded. > > > > > > 2. Recompile rtld with debug symbols and redo the build to get > > > the useful backtrace from core: > > > cd /usr/src/libexec/rtld-elf > > > make clean > > > make all install DEBUG_FLAGS=-g > > > > > Ok, someone who got the crash will have to do this as I couln't > > reproduce it here (sorry forgot to say...) > > > I just learned that the missing piece in reproducing this is the > pulseaudio knob, now I finally have a bt: > obj->nbuckets in core seems to disagree with that readelf thinks it should be (521 != 67). Could you please make the tarball of all the VLC libraries involved? Send the link to me and kib@, please. At the very least, can I lay my hands on libpulsesrc_plugin.so binary? -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Sat, 25 Feb 2012 10:41:59 -0800 Tim Kientzle wrote: > > On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote: > > > On Tue, 21 Feb 2012 21:11:13 -0800 > > Tim Kientzle wrote: > > > >> > >> If I understand correctly, the libgcc in base is pretty stripped > >> down compared to "regular" libgcc, because most of that > >> stuff is in our libc instead. > >> > > > > You understand it a bit wrong, but your conclusions are correct. > > libgcc in base is not stripped in any way and is supposed to be > > identical to one coming from upstream. > > So where is __umodsi3 supposed to be defined for ARM? > > In FreeBSD, libgcc refers to it but does not define it. > It's defined in libc. > > I stumbled across this trying to link some freestanding > ARM code using the native cross-compilers. The link > failed if I used -nostdlib because of a handful of symbols > such as this. > > Tim I do not know how embedded architectures split it these days and I am not even sure if we have an official ARM port in FSF GCC, but in general these belong in static portion of libgcc.a. If you'd look at bmake glue in gnu/lib/libgcc, you will see that building of __umodsi was there but was disabled by our arm folks presumably because of switch to our own complete softfloat implementation that happens to be in libc. They probably should not have disabled integer math stuff along with libgcc's incomplete floating point implementation, but I guess they had their reasons. Non-embedded architectures do not do that and for amd64/i386 each GCC import since 3. ensured that libgcc_s.so matched one produced by upstream symbol-by-symbol. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 21:11:13 -0800 Tim Kientzle wrote: > > On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > > > On Tue, 21 Feb 2012, Steve Kargl wrote: > > > >> 3) Add a new option to ldconfig to prepend new libraries to > >> the hints files and fix the ports to use this option instead > >> of -m. > > > > You don't want system binaries that want /lib/libgcc_s.so.1 > > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't > > your option 3 do that? > > Why not? Would it cause problems? > > Is libgcc from GCC 4.6 incompatible with /lib/libgcc? > > If I understand correctly, the libgcc in base is pretty stripped > down compared to "regular" libgcc, because most of that > stuff is in our libc instead. So if there were compatibility > problems, I'd expect those to show up when GCC 4.6 linked > programs against /usr/local/.../libgcc and /lib/libc. > You understand it a bit wrong, but your conclusions are correct. libgcc in base is not stripped in any way and is supposed to be identical to one coming from upstream. As long as upstream maintains backward compatibility, their library should be a perfect replacement for ours. There was a time period while FreeBSD used dynamic unwind into search using dl_iterate_phdr while upstream GCCs didn't, but that was fixed by GCC folks switching GCC to use dl_iterate_phdr on Linux and FreeBSD by default quite while ago. I am not aware of any other incompatibilities at this time. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl wrote:
> On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
> > On Tue, 21 Feb 2012, Steve Kargl wrote:
> >
> > >On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
> > >>On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
> > >>>On 2012-02-21 20:42, Steve Kargl wrote:
> > >>>...
> > >>>>Yes, /lib comes before /usr/local/lib/gcc46. I suppose
> > >>>>that this is a heads up for gerald@. lang/gcc is used by
> > >>>>the ports collections to build a large number of other
> > >>>>ports, so others are likely to hit this issue.
> > >>
> > >>Does -rpath not help ?
> > >
> > >I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
> > >to my various projects. I can also build with -static to avoid
> > >rtld. One can also use LD_LIBRARY_PATH.
> > >
> > >The issue seems to be that lang/gcc will be installed after
> > >system start, and 'ldconfig -m' appends new shared libraries
> > >to the hints file. This means that libraries with the same
> > >name but different locations will be found via the order of the
> > >search path in the hints file, and one gets the wrong library.
> > >That is, with the following
> > >
> > >troutmask:root[256] ldconfig -r | grep libgcc_s
> > > 29:-lgcc_s.1 => /lib/libgcc_s.so.1
> > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1
> > >
> > >29 will be found before 723. While I can work around the
> > >issue, lang/gcc is used by a rather large boatload of ports
> > >during the building process and I suspect that a large
> > >number of FreeBSD users use lang/gcc for their everyday
> > >compiler. The question is how do we, the FreeBSD project,
> > >deal with this issue, so that the general user base does not
> > >get hit with it.
> > >
> > >There are a few solutions:
> > >1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
> > > be scanned before /lib and /usr/lib.
> > >2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
> > > for /lib and /usr/lib.
> >
> > s/for/before/ ??
>
> yes. sorry about the typo.
>
> >
> > >3) Add a new option to ldconfig to prepend new libraries to
> > > the hints files and fix the ports to use this option instead
> > > of -m.
> >
> > You don't want system binaries that want /lib/libgcc_s.so.1
> > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
> > your option 3 do that?
>
> Well, yes, I suppose that could be a problem. :)
>
> > >4) Suggestions from people that are brighter than I.
> >
Well, newer libgcc_s.so.1 should be backward compatible with older
ones, so that should not be the problem and if there are any, we need
to find and fix them.
> > [Not brighter than you, but]
> >
> > o For our system libgcc, use libcc_s.so.1 (or some other
> > name) instead of libgcc_s.so.1?
>
> Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
> and binaries installed by lang/gcc updated to use this library.
>
'shared' portion of libgcc was meant to _be_ shared specifically and in
general having two copies of unwind code and two copied of unwind
frames handling logic is probably not what GCC is expecting.
> > o Change affected ports to use -rpath when building?
>
> I started to look into this option, but it quickly becomes
> apparent that some (evil) configure hackery may be needed.
>
It can be done in GCC specs for all the programs that use CC driver to
to the linking. Of course, all direct LD invocations will need to be
found and fixed as well, but those were always fragile anyway.
> --
> Steve
> ___
> freebsd-curr...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscr...@freebsd.org"
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 11:42:59 -0800 Steve Kargl wrote: > On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > > > > > troutmask:kargl[210] halfspace > > > /lib/libgcc_s.so.1: version GCC_4.6.0 required > > > by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] > > > > > > (Note, the annoying absense of a newline character after the error > > > message, which is a completely different issue.) > > > > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > > > > > troutmask:kargl[212] ldd ~/bin/halfspace > > > /home/kargl/bin/halfspace: > > > liblapack.so.4 => /usr/local/lib/liblapack.so.4 > > > (0x2008c3000) libblas.so.2 => /usr/local/lib/libblas.so.2 > > > (0x201463000) libgfortran.so.3 > > > => /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 > > > => /lib/libm.so.5 (0x201a7) libgcc_s.so.1 > > > => /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 > > > => /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 > > > => /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r > > > | grep libgcc_s 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > > > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > > > the lang/gcc port is no longer providing sufficient information > > > for rtld to choose the correct library. > > > > > > I have reverted revisions 230784, 299768, and 229508 (and > > > various combinitions of these revisions) from rtld-elf. The > > > result does not change the above error. > > > > > > I can work around the problem by specifying -static during > > > the building of my programs. Or, I can work around the > > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > > command line, which I have never had to do. > > > > > I highly suspect that you just happen to not need a symbol from the > > newest namespace before. > > > > The thing to look first is the library search path in the ld.so > > hints, which is output at the second line of ldconfig -r. I think > > that you have /lib before /usr/local/lib/gcc46 in your setup. This > > guess is confirmed by the numeration of the two instances of gcc_s > > above. Either change the config, or use -rpath. AFAIR, ldconfig -m > > adds the directory at the end of the search list. > > Yes, /lib comes before /usr/local/lib/gcc46. I suppose > that this is a heads up for gerald@. lang/gcc is used by > the ports collections to build a large number of other > ports, so others are likely to hit this issue. > > I tried reading rtld.c to see where the issue lies. One > possibility seems to be a change in rtld.c (lines 4012-13) > to remember the version mismatch, then continuing the search > to see if another library with the same name but different > location matches. After exhausting the list of directories > in the search path, either an error is reported or a match > has been found. Note, I'm still trying to parse and understand > the rtld.c code, so may be what I'm suggesting is not > feasible. > This was suggested before in a slightly different context and at the time I was not big fan of the idea. With more ports starting to use out of tree GCC, maybe we need to revisit the idea. There are corner cases that I do not know how to handle in this approach: what happens if we have mapped system libgcc_s.so.1 already which did satisfy all the requirements and later a new library gets mapped in dynamically and requires symbol versions from newer GCC? Going with this suggestion will likely involve substantial changes into rtld dependency walking code - we'll need to make a graph traversal and collect all the version information from all the libraries that might satisfy the search before doing the final pass of loading the winning candidates, which implies at least two dependency tree passes. And, given the above, it won't even give us what we want anyway as long as there's dlopen in the picture, so I'd say it is not worth the trouble. Just changing the compiler to supply rpath on binaries it builds might be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware, etc) are doing this for ages and mostly manage to pull things off. Third option is of course purging _all_ toolchain components out of the tree, which is such a fine bikeshed material that I am a bit scared to bring that up. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 21:20:12 +0100 Alexey Shuvaev wrote: > On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote: > > On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev > > wrote: > > > Hello! > > > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month > > > now [1]. Examining build log and reproducing it locally, the > > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. > > > The linker fails to produce libxpcom_core.so although > > > -L/usr/local/lib and -liconv are specified [2]. Examining this > > > further I found that ..o produced with [3] > > > fails to link with libiconv alone too [4] (note still unresolved > > > libiconv references). I'm not a compiler/linker guru and do not > > > understand what is happening here. As a workaroud I use the > > > attached patch which disables the usage of libiconv in > > > nsNativeCharsetUtils.cpp. > > > > ls /usr/local/lib/libiconv*so* ? > > > ~> ll /usr/local/lib/libiconv*so* > lrwxr-xr-x 1 root wheel 13 Jan 27 > 13:14 /usr/local/lib/libiconv.so -> libiconv.so.3 -r--r--r-- 1 root > wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3 > > I'm not so lame :) > > On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote: > > On Sat, 29 Jan 2011 13:21:44 -0500 > > Alexander Kabaev wrote: > > > > > On Sat, 29 Jan 2011 13:02:24 -0500 (EST) > > > Daniel Eischen wrote: > > > > > > > On Sat, 29 Jan 2011, Alexey Shuvaev wrote: > > > > > > > > > Hello! > > > > > > > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 > > > > > month now [1]. Examining build log and reproducing it > > > > > locally, the problem is in the usage of libiconv in > > > > > nsNativeCharsetUtils.cpp. The linker fails to produce > > > > > libxpcom_core.so although -L/usr/local/lib and -liconv are > > > > > specified [2]. Examining this further I found that > > > > > nsNativeCharsetUtils.o produced with [3] fails to link with > > > > > libiconv alone too [4] (note still unresolved libiconv > > > > > references). I'm not a compiler/linker guru and do not > > > > > understand what is happening here. As a workaroud I use the > > > > > attached patch which disables the usage of libiconv in > > > > > nsNativeCharsetUtils.cpp. > > > > > > > > Yes, I had this problem also on -current. Does seamonkey build > > > > on recent 8.x? > > > > > > > > libxpcomio_s.a is a static library that has unresolved > > > > references to libiconv. I guess I'd expect those references to > > > > be resolved with a later -L/usr/local/lib -liconv when building > > > > the shared library (libxpcom_core.so), but they are not. > > > > > > > > > > My wild guess: seamonkey tries to hide symbols that are coming > > > from different .o file (this time one from libiconv.a) and that > > > fails with our toolchain. > > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 > > > -- > > > Alexander Kabaev > > > > Follow-up to myself: Nope, the fix to said bug appears in our > > compiler. Can you make amd64 version of nsNativeCharsetUtils. > > -- > > Alexander Kabaev > > > ??? (It is already on amd64) Email was sent while not finished. Can you make amd64 version of nsNativeCharsetUtils.o available from somewhere along with corresponding .ii file? To get .ii file you can add -save-temps to GCC invocation used to compile nsNativeCharsetUtils.cpp. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen wrote: > On Sat, 29 Jan 2011, Alexey Shuvaev wrote: > > > Hello! > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month > > now [1]. Examining build log and reproducing it locally, the > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. > > The linker fails to produce libxpcom_core.so although > > -L/usr/local/lib and -liconv are specified [2]. Examining this > > further I found that nsNativeCharsetUtils.o produced with [3] fails > > to link with libiconv alone too [4] (note still unresolved libiconv > > references). I'm not a compiler/linker guru and do not understand > > what is happening here. As a workaroud I use the attached patch > > which disables the usage of libiconv in nsNativeCharsetUtils.cpp. > > Yes, I had this problem also on -current. Does seamonkey build > on recent 8.x? > > libxpcomio_s.a is a static library that has unresolved references > to libiconv. I guess I'd expect those references to be resolved > with a later -L/usr/local/lib -liconv when building the shared > library (libxpcom_core.so), but they are not. > My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev wrote: > On Sat, 29 Jan 2011 13:02:24 -0500 (EST) > Daniel Eischen wrote: > > > On Sat, 29 Jan 2011, Alexey Shuvaev wrote: > > > > > Hello! > > > > > > It seems www/seamonkey2 is broken on CURRENT for at least 1 month > > > now [1]. Examining build log and reproducing it locally, the > > > problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. > > > The linker fails to produce libxpcom_core.so although > > > -L/usr/local/lib and -liconv are specified [2]. Examining this > > > further I found that nsNativeCharsetUtils.o produced with [3] > > > fails to link with libiconv alone too [4] (note still unresolved > > > libiconv references). I'm not a compiler/linker guru and do not > > > understand what is happening here. As a workaroud I use the > > > attached patch which disables the usage of libiconv in > > > nsNativeCharsetUtils.cpp. > > > > Yes, I had this problem also on -current. Does seamonkey build > > on recent 8.x? > > > > libxpcomio_s.a is a static library that has unresolved references > > to libiconv. I guess I'd expect those references to be resolved > > with a later -L/usr/local/lib -liconv when building the shared > > library (libxpcom_core.so), but they are not. > > > > My wild guess: seamonkey tries to hide symbols that are coming from > different .o file (this time one from libiconv.a) and that fails with > our toolchain. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 > -- > Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. -- Alexander Kabaev signature.asc Description: PGP signature
Re: svn commit: r195697 - in head: . contrib/gcc/config gnu/lib/libgcc gnu/lib/libssp/libssp_nonshared lib/libc lib/libc/sys libexec/rtld-elf share/mk
On Thu, 16 Jul 2009 22:00:28 + "b. f." wrote: > >Author: kan > >Date: Tue Jul 14 21:19:13 2009 > >New Revision: 195697 > >URL: http://svn.freebsd.org/changeset/base/195697 > > >Log: > > Second attempt at eliminating .text relocations in shared libraries > > compiled with stack protector. > > Unfortunately, on r195705 i386 (world and kernel), this breaks a clean > (i.e., no other ports or packages installed, clean work directory) > build of lang/perl5.8 or lang/perl5.10 with -fstack-protector or > -fstack-protector-all in the CFLAGS, using the base system compiler: > > LD_LIBRARY_PATH=/tmp/usr/ports/lang/perl5.8/work/perl-5.8.9 cc > -pthread -Wl,-E -L/usr/local/lib -o miniperl `echo gv.o toke.o > perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o > perl.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o > doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o > perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o | > sed 's/ op.o / /'` miniperlmain.o opmini.o -lm -lcrypt -lutil > *** Error code 1 > > Stop in /usr/ports/lang/perl5.8. > *** Error code 1 > > > I would not be surprised to find that it affects a large number of > other ports in a similar manner. So it seems that some further > changes are required. > > Regards, > b. The port does not pass -fstack-protector to link command line and is broken. -- Alexander Kabaev signature.asc Description: PGP signature
Re: ImageMagick's "modules" and __cxa_finalize
On Sun, 29 Jul 2007 23:31:10 -0400
Mikhail Teterin <[EMAIL PROTECTED]> wrote:
> Has anyone had any luck using ImageMagick built with modules support?
>
> If I try that, and follow-up with `gmake check' (in the ${WRKSRC}),
> about a fifth of ImageMagick's own self-tests seg-fault -- all of
> them inside __cxa_finalize (after main() has already returned):
>
> [EMAIL PROTECTED]:ImageMagick/work/ImageMagick-6.3.5 (1023) gdb
> tests/.libs/rwblob tests/rwblob.core [...]
> (gdb) where 5
> #0 0x000804008cc0 in ?? ()
> #1 0x0008020079e2 in __cxa_finalize ()
> from /lib/libc.so.6 #2 0x000802007637 in exit ()
> from /lib/libc.so.6 #3 0x00401135 in _start ()
> #4 0x00080052a000 in ?? ()
> (More stack frames follow...)
> (gdb)
> [EMAIL PROTECTED]:ImageMagick/work/ImageMagick-6.3.5 (1024) gdb
> tests/.libs/rwfile tests/rwfile.core [...]
> (gdb) where 5
> #0 0x000803f04cc0 in ?? ()
> #1 0x0008020079e2 in __cxa_finalize ()
> from /lib/libc.so.6 #2 0x000802007637 in exit ()
> from /lib/libc.so.6 #3 0x00401085 in _start ()
> #4 0x00080052a000 in ?? ()
> (More stack frames follow...)
> (gdb)
>
> Full build/test log can be seen here:
>
> http://aldan.algebra.com/~mi/IM-6.3.5-3.failure.log
>
> Building without modules (as is the port's default) allows all
> self-tests to pass smoothly.
>
> According to ImageMagick and GraphicsMagick developers, these crashes
> are due to some "reckless" calls to atexit() from inside the modules
> (or inside the modules-loaded graphics librarires). By the time the
> program is exiting, the libraries with the atexit-loaded functions
> may already be unloaded.
>
> But I thought, FreeBSD had that case covered since 2003:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=59552
>
> Can someone, please, comment?
>
> -mi
You thought wrong.
Please read the PR again and try to understand what part it really does
cover and what doesn't. The comment was given to you before and it is
the right one:
atexit() cannot be used safely from the shared library.
That is the reason why __cxa_atexit was invented in the first place.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: DSO loading (dlopen) appearse to be broken somehow
On Wed, 4 Apr 2007 16:57:35 +0400 Andrey Chernov <[EMAIL PROTECTED]> wrote: > On Wed, Apr 04, 2007 at 08:23:46AM -0400, Alexander Kabaev wrote: > > > Syntax error on line 213 of /usr/local/etc/apache/httpd.conf: > > > Cannot load /usr/local/libexec/apache/mod_env.so into server: > > > /usr/local/libexec > > > /apache/mod_env.so: Undefined symbol "ap_palloc" > > > > > > Perhaps it is Apache configuration problem since old-compiled > > > apache (Dec 9) runs normally. Perhaps Apache config find some new > > > defines which not works as expected. > > > > > > I am not expert in dlopen() at all. Please look someone who knows. > > > > > You do not have to be an expert in dlopen to find out the list of > > loaded modules at the time dlopen called, what parameters dlopen is > > called with and where the symbol allegedly not found is really > > defined. > > 1) The symbols in question are all _defined_ inside main httpd > program. objdump -T output goes here. 2) dlopen() just call single first apache module and fails. dlopen parameters dump goes here. 2a) dlerror() output goes here objdump -T of module being loaded goes here too. > 3) Apache port not changed for a long time and works at the moment of > last commit 2006/12/09 Symbol lookup and module loading has not changed in rtld for even longer time. You honestly expect someone to do initial trivial investigation for you? -- Alexander Kabaev signature.asc Description: PGP signature
Re: DSO loading (dlopen) appearse to be broken somehow
On Wed, 4 Apr 2007 14:13:21 +0400 Andrey Chernov <[EMAIL PROTECTED]> wrote: > Try to install and run www/apache13 port. With recent -current you'll > get similar error for each module first listed in config: > > Syntax error on line 213 of /usr/local/etc/apache/httpd.conf: > Cannot load /usr/local/libexec/apache/mod_env.so into server: > /usr/local/libexec > /apache/mod_env.so: Undefined symbol "ap_palloc" > > Perhaps it is Apache configuration problem since old-compiled apache > (Dec 9) runs normally. Perhaps Apache config find some new defines > which not works as expected. > > I am not expert in dlopen() at all. Please look someone who knows. > You do not have to be an expert in dlopen to find out the list of loaded modules at the time dlopen called, what parameters dlopen is called with and where the symbol allegedly not found is really defined. -- Alexander Kabaev signature.asc Description: PGP signature
Re: GCC 4.1 configure help
On Sat, 16 Sep 2006 12:29:33 +0400 Stanislav Sedov <[EMAIL PROTECTED]> wrote: > On Fri, 15 Sep 2006 21:05:04 -0400 > Alexander Kabaev <[EMAIL PROTECTED]> mentioned: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Hi, > > > > I do not have access to any PowerPC machines running FreeBSD, so I > > would like to ask for your help. Could someone please go to > > /usr/ports/lang/gcc41 start the build and then collect the > > auto-host.h file from the work/build/gcc/ directory? Or better yet, > > _all_ header files from work/build? > > > > This will help me to ensure I won't miss any special configuration > > tweak for an upcoming gcc 4.1 compiler update in the tree. There is > > only so much I can to using cross-compiled toolchain. > > > > I am not subscribed to the list, so please reply directly to this > > address or kan at FreeBSD.org. > > > > When you plan to perform gcc upgrade? This will probably make a huge > regression in ports, thus it needs full run on cluster first, that > will help us to fix affected ports. > > In fact, even 3.4.4 -> 3.4.6 upgrade broke some ports. > > Thanks! > > -- > Stanislav Sedov MBSD labs, Inc. <[EMAIL PROTECTED]> > Россия, Москва http://mbsd.msk.ru What is the point of this message? I asked for help and unless you have a file I asked for, please spare me the lecture on how to do compiler updates. I did it several times and full package runs on multiple architectures were mandatory with all of them, as Kris can attest. Every compiler update breaks some ports, due to new bugs or more often due to even more anal code correctness checks implemented with every new major GCC release. Depending on their seriousness, GCC bugs are either getting fixed in upstream sources or worked around locally, but dealing with GCC strictness was always been something that port maintainers were supposed to do themselves. 3.4.4 - 3.4.6 update broke ports that had the code GCC no longer accepts as valid C++. -- Alexander Kabaev -- Alexander Kabaev signature.asc Description: PGP signature
