Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more)

2017-07-19 Thread Alexander Kabaev 
On Wed, 19 Jul 2017 22:50:04 +0200 (CEST)
Gerald Pfeifer <ger...@pfeifer.com> 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)

2017-04-14 Thread Alexander Kabaev 
On Sat, 15 Apr 2017 09:30:49 +1000 (AEST)
Gerald Pfeifer <ger...@pfeifer.com> 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

2012-08-23 Thread Alexander Kabaev 
On Thu, 23 Aug 2012 18:19:57 -0400
Steve Wills swi...@freebsd.org 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)

2012-08-20 Thread Alexander Kabaev 
On Mon, 20 Aug 2012 13:15:10 +0300
Konstantin Belousov kostik...@gmail.com 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
   n...@jelal.kn-bremen.de 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! :)

2012-08-13 Thread Alexander Kabaev 
On Mon, 13 Aug 2012 01:12:10 +0200
Juergen Lock n...@jelal.kn-bremen.de 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:
SKIP
 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: Another vlc 2.0.3 update (new ffmpeg! :)

2012-08-13 Thread Alexander Kabaev 
On Mon, 13 Aug 2012 23:52:12 +0200
Juergen Lock n...@jelal.kn-bremen.de 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 kab...@gmail.com 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: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)

2012-08-12 Thread Alexander Kabaev 
On Mon, 13 Aug 2012 01:13:35 +0200
Juergen Lock n...@jelal.kn-bremen.de 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

2012-02-25 Thread Alexander Kabaev 
On Sat, 25 Feb 2012 10:41:59 -0800
Tim Kientzle t...@kientzle.com wrote:

 
 On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote:
 
  On Tue, 21 Feb 2012 21:11:13 -0800
  Tim Kientzle t...@kientzle.com 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.something 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

2012-02-23 Thread Alexander Kabaev 
On Tue, 21 Feb 2012 21:11:13 -0800
Tim Kientzle t...@kientzle.com 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

2012-02-21 Thread Alexander Kabaev 
On Tue, 21 Feb 2012 11:42:59 -0800
Steve Kargl s...@troutmask.apl.washington.edu 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: rtld or lang/gcc cannot find libgcc_s.so.1

2012-02-21 Thread Alexander Kabaev 
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl s...@troutmask.apl.washington.edu 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: [WORKAROUND] www/seamonkey2 on CURRENT

2011-01-29 Thread Alexander Kabaev 
On Sat, 29 Jan 2011 13:21:44 -0500
Alexander Kabaev kab...@gmail.com wrote:

 On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
 Daniel Eischen deisc...@freebsd.org 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: [WORKAROUND] www/seamonkey2 on CURRENT

2011-01-29 Thread Alexander Kabaev 
On Sat, 29 Jan 2011 21:20:12 +0100
Alexey Shuvaev shuv...@physik.uni-wuerzburg.de 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
  shuv...@physik.uni-wuerzburg.de 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 kab...@gmail.com wrote:
  
   On Sat, 29 Jan 2011 13:02:24 -0500 (EST)
   Daniel Eischen deisc...@freebsd.org 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: 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

2009-07-16 Thread Alexander Kabaev 
On Thu, 16 Jul 2009 22:00:28 +
b. f. bf1...@googlemail.com 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:
 

SKIP

 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

2007-07-31 Thread Alexander Kabaev 
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:

COMMENT
atexit() cannot be used safely from the shared library.
/COMMENT


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

2007-04-04 Thread Alexander Kabaev 
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: DSO loading (dlopen) appearse to be broken somehow

2007-04-04 Thread Alexander Kabaev 
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