Re: [blfs-support] SDL-1.2.15 Build Fails (chrooted environment)

[Craig Jackson]

In 7.10-systemd stable I used the attached patch to get SDL-1.2.15 to
compile.  Looks like this has been applied upstream in
http://hg.libsdl.org/SDL/rev/91ad7b43317a.

Took me a minute to find the appropriate fix for this specific version.

Thanks!


Craig Jackson
craigmjack...@gmail.com
253-459-5384 cell

On Sun, Jul 14, 2013 at 3:22 AM, Ken Moffat  wrote:

> On Sat, Jul 13, 2013 at 10:19:14PM -0500, Bruce Dubbs wrote:
> >
> > This works for me:
> >
> > SUDO=sudo
> > PROGRAM=SDL-1.2.15
> >
> > sed -i '/_XData32/d' src/video/x11/SDL_x11sym.h &&
> >
> > ./configure --prefix=/usr  &&
> > make   &&
> >
> > echo "BLFS Start INSTALL"  &&
> > $SUDO make install &&
> > $SUDO install -v -m755 -d   /usr/share/doc/$PROGRAM/html &&
> > $SUDO install -v -m644  docs/html/*.html
> >  /usr/share/doc/$PROGRAM/html
> >
> > I think we need to add the sed to the book.
> >
> >-- Bruce
>
>  If we can find out *why* it's needed - I was going to say that it
> built fine for me on LFS-svn from late April (and before that,
> including 7.3), but I decided to retry.  [ rude words ] - now I too
> get :
> In file included from ./src/video/x11/SDL_x11dyn.h:34:0,
>  from ./src/video/x11/SDL_x11dyn.c:26:
> /usr/include/X11/Xlibint.h:595:12: note: previous declaration of
> ‘_XData32’ was here
>  extern int _XData32(
>
>  That is part of the Xorg updates (libX11-1.6.0).  I don't see any
> obvious changes in the header itself that would cause LONG64 to now
> be defined, but obviously somewhere in Xorg is now doing that.
>
>  I'm guessing that all the failures were on x86_64 ?
>
>  Google tells me (e.g.
> http://cgit.freedesktop.org/xorg/lib/libXp/commit/?id=
> 15ec6d1d0bb8c4cb24a190ed34e63312a0623670
> ) that this is from X11/Xmd.h and it is indeed part of the recent
> long-standing vulnerability fixes.  Xmd.h comes from xproto, and the
> change for 7.0.24 was:
>
> ken@jtm1 /scratch/ken $diff -u xproto-7.0.2{3,4}/Xmd.h
> --- xproto-7.0.23/Xmd.h 2012-03-16 06:11:44.0 +
> +++ xproto-7.0.24/Xmd.h 2013-03-29 23:26:53.0 +
> @@ -64,7 +64,9 @@
>   defined(__s390x__) || \
>   defined(__amd64__) || defined(amd64) || \
>   defined(__powerpc64__)
> -#  define LONG64   /* 32/64-bit
> architecture */
> +#  if !defined(__ILP32__) /* amd64-x32 is 32bit */
> +#   define LONG64  /* 32/64-bit
> architecture */
> +#  endif /* !__ILP32__ */
>  # endif
>
>  /*
>
>  So yes, we do need it in the book.  And I see Igor has already
> fixed it :)
>
> ĸen
> --
> das eine Mal als Tragödie, das andere Mal als Farce
> --
> http://linuxfromscratch.org/mailman/listinfo/blfs-support
> FAQ: http://www.linuxfromscratch.org/blfs/faq.html
> Unsubscribe: See the above information page
>

# HG changeset patch
# User Azamat H. Hackimov 
# Date 1370184533 -21600
# Node ID 91ad7b43317a6387e115ecdf63a49137f47e42c8
# Parent  f7fd5c3951b9ed922fdf696f7182e71b58a13268
Fix compilation with libX11 >= 1.5.99.902.

These changes fixes bug #1769 for SDL 1.2
(http://bugzilla.libsdl.org/show_bug.cgi?id=1769).

diff -r f7fd5c3951b9 -r 91ad7b43317a configure.in
--- a/configure.in	Wed Apr 17 00:56:53 2013 -0700
+++ b/configure.in	Sun Jun 02 20:48:53 2013 +0600
@@ -1169,6 +1169,17 @@
 if test x$definitely_enable_video_x11_xrandr = xyes; then
 AC_DEFINE(SDL_VIDEO_DRIVER_X11_XRANDR)
 fi
+AC_MSG_CHECKING(for const parameter to _XData32)
+have_const_param_xdata32=no
+AC_TRY_COMPILE([
+  #include 
+  extern int _XData32(Display *dpy,register _Xconst long *data,unsigned len);
+],[
+],[
+have_const_param_xdata32=yes
+AC_DEFINE(SDL_VIDEO_DRIVER_X11_CONST_PARAM_XDATA32)
+])
+AC_MSG_RESULT($have_const_param_xdata32)
 fi
 fi
 }
diff -r f7fd5c3951b9 -r 91ad7b43317a include/SDL_config.h.in
--- a/include/SDL_config.h.in	Wed Apr 17 00:56:53 2013 -0700
+++ b/include/SDL_config.h.in	Sun Jun 02 20:48:53 2013 +0600
@@ -283,6 +283,7 @@
 #undef SDL_VIDEO_DRIVER_WINDIB
 #undef SDL_VIDEO_DRIVER_WSCONS
 #undef SDL_VIDEO_DRIVER_X11
+#undef SDL_VIDEO_DRIVER_X11_CONST_PARAM_XDATA32
 #undef SDL_VIDEO_DRIVER_X11_DGAMOUSE
 #undef SDL_VIDEO_DRIVER_X11_DYNAMIC
 #undef SDL_VIDEO_DRIVER_X11_DYNAMIC_XEXT
diff -r f7fd5c3951b9 -r 91ad7b43317a src/video/x11/SDL_x11sym.h
--- a/src/video/x11/SDL_x11sym.h	Wed Apr 17 00:56:53 2013 -0700
+++ b/src/video/x11/SDL_x11sym.h	Sun Jun 02 20:48:53 2013 +0600
@@ -165,7 +165,11 @@
  */
 #ifdef LONG64
 SDL_X11_MODULE(IO_32BIT)
+#if SDL_VIDEO_DRIVER_X11_CONST_PARAM_XDATA32
+SDL_X11_SYM(int,_XData32,(Display *dpy,register _Xconst long *data,unsigned len),(dpy,data,len),return)
+#else
 SDL_X11_SYM(int,_XData32,(Display *dpy,register long *data,unsigned len),(dpy,data,len),return)
+#endif
 

[blfs-support] systemd units

[Riccardo Corsi]

Hello, I'm building 7.10 BLFS systemd.
In:
http://linuxfromscratch.org/blfs/view/stable-systemd/introduction/systemd-units.html
I had an error in download.

I have downloaded from
http://www.linuxfromscratch.org/blfs/downloads/7.10-systemd/blfs-systemd-units-20160602.tar.bz2
instead.

Please check url in the site.

Regards.

Riccardo
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Updates Without Crashing LFS

[Ken Moffat]

On Wed, Sep 14, 2016 at 09:41:04AM -0400, Wayne Sallee wrote:
> On 09/13/2016 05:12 PM, Ken Moffat wrote:
> > On Wed, Sep 14, 2016 at 06:40:33AM +1000, Samuel Tyler wrote:
> > > Ok, I understand all this. So what happens (for example) if I have
> > > installed GCC 6.1.0 and I want to upgrade to GCC 6.2.0. If I was not to
> > > rebuild the entire system, and I just ran the configure make make install
> > > commands in the book, would it _entirely_ replace GCC 6.1.0?
> > > 
> > Please do not top post.
> > 
> > As with most package upgrades, things are left behind unless you
> > specifically remove them afterwards.
> > 
> > In most cases, this is not a problem.  If '/' is comparatively small,
> > after doing some upgrades of big packages you might need to clear out
> > some of the things left behind so that you have enough space.
> > 
> > What it _will_ do is replace the executables, the libraries in
> > /usr/lib, and the info files and manpages.
> > 
> > The things left behind are in the versioned directories in:
> > /usr/include/c++/
> > /usr/lib/gcc/x86_64-unknown-linux-gnu/
> > /usr/libexec/gcc/x86_64-pc-linux-gnu/
> > /usr/share/
> > 
> > ĸen
> 
> Do you prefer to install over, with gcc, or uninstall, then install?
> 
Neither - I very rarely need a newer version of gcc (as I think I
said, my svn versions of the books only normally get used for short
periods, and the releases which I keep are usually only in "main"
use until the next release.

If I'm building an svn (or pre-svn, to try a newer part of the
toolchain) version of LFS, it's always a fresh start - even if
(occasionally) they go nowhere.

If you want to want to update gcc there should be no problem - just
build it.  Some people keep several versions around for build tests
with newer snapshots, but in that case it might be better to give
each its own prefix so that you can easily control which one is
first on the PATH.

And in LFS, 'make uninstall' is often a very bad idea : for some
packages/versions it might not have had a lot of testing and could
conceivably remove more than you expected.  And for gcc, I think the
risk of breaking something if you uninstall the existing gcc just
before installing the new one [ i.e. after make ] is not worth the
risk.

ĸen
-- 
`I shall take my mountains', said Lu-Tze. `The climate will be good
for them.' -- Small Gods
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-support] Updates Without Crashing LFS

[Wayne Sallee]

On 09/13/2016 05:12 PM, Ken Moffat wrote:

On Wed, Sep 14, 2016 at 06:40:33AM +1000, Samuel Tyler wrote:

Ok, I understand all this. So what happens (for example) if I have
installed GCC 6.1.0 and I want to upgrade to GCC 6.2.0. If I was not to
rebuild the entire system, and I just ran the configure make make install
commands in the book, would it _entirely_ replace GCC 6.1.0?


Please do not top post.

As with most package upgrades, things are left behind unless you
specifically remove them afterwards.

In most cases, this is not a problem.  If '/' is comparatively small,
after doing some upgrades of big packages you might need to clear out
some of the things left behind so that you have enough space.

What it _will_ do is replace the executables, the libraries in
/usr/lib, and the info files and manpages.

The things left behind are in the versioned directories in:
/usr/include/c++/
/usr/lib/gcc/x86_64-unknown-linux-gnu/
/usr/libexec/gcc/x86_64-pc-linux-gnu/
/usr/share/

ĸen


Do you prefer to install over, with gcc, or uninstall, then install?

Wayne Sallee
wa...@waynesallee.com
http://www.WayneSallee.com
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page