Rebase of the pr-msvc-support branch?
Hi! I'm wondering how to proceed; some of the patches in the pr-msvc-support branch no longer apply cleanly to git-head. So, before things get totally out of hand, I would like to rebase the branch. However, I have never rebased anything before. I could probably rebase my own repo, but I don't know how to push that rebase to the repo on savannah. man git-rebase only talks about rebasing a local repo, and there are big fat warnings about rebasing when you are collaborating with others... Should I kill the branch on savannah, rebase my local tree and finally push a brand new pr-msvc-support branch? Should I create a new topic branch named pr-msvc-support2? Should I merge git-head into the branch? That sure feels backwards, but what do I know? Please help. I have exported 22 patches from my git repo (three or four are not yet pushed to the savannah repo) and have modified those that need modification so that they apply cleanly to git-head, so I know exactly what needs to be done. At least I think I do, I haven't tested the result yet... BTW, I think some of those patches have merit on their own and could probably be cherry-picked into git-head, if someone cares enough. One final minor question, should we skip the patches to ChangeLog in the branch and recreate that part of the patches when/if the branch is merged? It seems that there is approximately 100% risk for the ChangeLog hunk to cause merge problems. Cheers, Peter
Re: Rebase of the pr-msvc-support branch?
Someone needs to cut the next libtool so that we can bite the bullet and integrate your branch into mainline. Bob == Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Cannot link correct libltdl.so. Is it a bug?
I got errors when I do the cross compile for powerpc. Below are the error
messages. It looks for /usr/lib/libltdl.so instead of
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so at link time. I set the path
-L/tools/eldk/4.2/ppc_4xx/usr/lib. But, it is useless. Below are details.
Before running ./configure, I set the environment variables below
setenv LDFLAGS -L/tools/eldk/4.2/ppc_4xx/usr/lib
setenv CPPFLAGS -I/tools/eldk/4.2/ppc_4xx/usr/include
setenv CROSS_COMPILE ppc_4xx-
setenv ARCH powerpc
setenv BUILD_CC gcc
setenv CC powerpc-linux-gcc
setenv AR powerpc-linux-ar
setenv RANLIB powerpc-linux-ranlib
set path=(/tools/eldk/4.2/bin /tools/eldk/4.2/usr/bin $path)
./configure --prefix=/tmp/install_libs --host=powerpc-linux
--build=i686-pc-linux-gnu -target=powerpc-linux
./configure runs successfully with the following warnings
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet. If you think this
configuration is useful to you, please write to autoc...@gnu.org.
Package libexif was not found in the pkg-config search path.
Perhaps you should add the directory containing `libexif.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libexif' found
config.status: WARNING: po/Makefile.in.in seems to ignore the --datarootdir
setting
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet. If you think this
configuration is useful to you, please write to autoc...@gnu.org.
Package libusb was not found in the pkg-config search path.
Perhaps you should add the directory containing `libusb.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libusb' found
./configure: line 26092: test: : integer expression expected
Package dbus-1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `dbus-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'dbus-1' found
config.status: WARNING: po/Makefile.in.in seems to ignore the --datarootdir
setting
make errors:
/bin/sh ../libtool --tag=CC --mode=link powerpc-linux-gcc -g -O2 -g -O2
-no-undefined -export-symbols ./libgphoto2_port.sym -version-info 8:0:8
-L/tools/eldk/4.2/ppc_4xx/usr/lib -o libgphoto2_port.la -rpath
/tmp/safebox/install_libs/lib libgphoto2_port_la-gphoto2-port-info-list.lo
libgphoto2_port_la-gphoto2-port-log.lo
libgphoto2_port_la-gphoto2-port-version.lo libgphoto2_port_la-gphoto2-port.lo
libgphoto2_port_la-gphoto2-port-portability.lo
libgphoto2_port_la-gphoto2-port-result.lo -lltdl
echo "{ global:" > .libs/libgphoto2_port.ver
cat ./libgphoto2_port.sym | sed -e "s/\(.*\)/\1;/" >> .libs/libgphoto2_port.ver
echo "local: *; };" >> .libs/libgphoto2_port.ver
powerpc-linux-gcc -shared .libs/libgphoto2_port_la-gphoto2-port-info-list.o
.libs/libgphoto2_port_la-gphoto2-port-log.o
.libs/libgphoto2_port_la-gphoto2-port-version.o
.libs/libgphoto2_port_la-gphoto2-port.o
.libs/libgphoto2_port_la-gphoto2-port-portability.o
.libs/libgphoto2_port_la-gphoto2-port-result.o
-L/tools/eldk/4.2/ppc_4xx/usr/lib /usr/lib/libltdl.so -Wl,-soname
-Wl,libgphoto2_port.so.0 -Wl,-version-script -Wl,.libs/libgphoto2_port.ver -o
.libs/libgphoto2_port.so.0.8.0
/usr/lib/libltdl.so: could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[4]: *** [libgphoto2_port.la] Error 1
make[4]: Leaving directory
`/projects/svdc/P4wsIPCSW/buildsw_safebox/safebox/libs/libgphoto2-2.4.2/libgphoto2_port/libgphoto2_port'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/projects/svdc/P4wsIPCSW/buildsw_safebox/safebox/libs/libgphoto2-2.4.2/libgphoto2_port'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/projects/svdc/P4wsIPCSW/buildsw_safebox/safebox/libs/libgphoto2-2.4.2/libgphoto2_port'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/projects/svdc/P4wsIPCSW/buildsw_safebox/safebox/libs/libgphoto2-2.4.2'
make: *** [all] Error 2
svdclc313:[~][] (66)> ls -alF /tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.*
-rw-r--r--1 tooladm toolsup 29788 Apr 1 2008
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.a
-rwxr-xr-x1 tooladm toolsup 791 Apr 1 2008
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.la*
lrwxrwxrwx1 tooladm toolsup16 Apr 15 2008
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so -> libltdl.so.3.1.4*
lrwxrwxrwx1 tooladm toolsup16 Apr 15 2008
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so.3 -> libltdl.so.3.1.4*
-rwxr-xr-x1 tooladm toolsup 32136 Apr 1 2008
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so.3.1.4*
Can someone tell me how to run configure so that it looks for
/tools/eldk/4.2/ppc_4xx/usr/lib/libltdl.so instead of /usr/lib/libltdl.so?
Is it a bug?
Thank you
Re: Rebase of the pr-msvc-support branch?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Peter Rosin on 1/8/2009 12:43 PM: > Should I kill the branch on savannah, rebase my local tree and finally > push a brand new pr-msvc-support branch? Should I create a new topic > branch named pr-msvc-support2? Should I merge git-head into the branch? > That sure feels backwards, but what do I know? Please help. Now that you've told us the branch will be rebased, it makes sense to just keep the same branch name, rebase locally, then push that rebased branch in place of the current one. Rebasing topic branches is acceptable with advance warning, and as long as we don't rebase the master branch. > One final minor question, should we skip the patches to ChangeLog in > the branch and recreate that part of the patches when/if the branch is > merged? It seems that there is approximately 100% risk for the > ChangeLog hunk to cause merge problems. Check out Bruno Haible's git-merge-changelog, currently in the gnulib repository. It handles rebasing/merging of ChangeLog entries with minimal hassle, reducing the risk of a ChangeLog merge interfering with your rebase from 100% down to about 2%. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklmvVwACgkQ84KuGfSFAYBDnACeNFJnSH1GEGIwAWt0h1JfXfMJ vY8AniR9sshdBEkqEvCupRchs18Kf38J =jvW4 -END PGP SIGNATURE-
Re: Rebase of the pr-msvc-support branch?
Peter Rosin writes: > Should I kill the branch on savannah, rebase my local tree and finally > push a brand new pr-msvc-support branch? Should I create a new topic > branch named pr-msvc-support2? Should I merge git-head into the branch? > That sure feels backwards, but what do I know? Please help. As a practical matter, I've found that Git at Savannah is configured to prevent updating a branch other than through a "fast forward", even if you use the "+" syntax on git-push. That means that pushing a rebased version of a branch won't work. If the libtool Git is set up that way, you can work around the problem by first deleting the branch, then creating a new branch with the same name as the old one with the rebased content, e.g. git push origin :pr-msvc-support # Delete branch. git push origin HEAD:pr-msvc-support # Recreate branch. -- Ben Pfaff http://benpfaff.org
Re: [PATCH] [cygwin|mingw] Fix compile warnings when -std=c89.
Charles Wilson wrote: > * libltdl/config/ltmain.m4sh: Update copyright date. > (func_emit_wrapper_part1): move contents to... > (func_emit_wrapper_part2): move contents to... > (func_emit_wrapper): here. > (func_emit_cwrapperexe_src) [file scope]: re-organized > includes and portability macros. Avoid oldnames on MINGW32 > and MSVC for setmode/stat/chmod/getcwd/putenv. Declare > _putenv on MINGW32 when -ansi. Use namespaced macro > LT_DEBUGWRAPPER. Remove variables script_text_part1 and > script_text_part2. > (func_emit_cwrapperexe_src) [lt_dump_script]: New function. > (func_emit_cwrapperexe_src) [main]: Call it. Ping?
Re: Rebase of the pr-msvc-support branch?
* Eric Blake wrote on Fri, Jan 09, 2009 at 03:58:36AM CET: > According to Peter Rosin on 1/8/2009 12:43 PM: > > Should I kill the branch on savannah, rebase my local tree and finally > > push a brand new pr-msvc-support branch? > Now that you've told us the branch will be rebased, it makes sense to just > keep the same branch name, rebase locally, then push that rebased branch > in place of the current one. Rebasing topic branches is acceptable with > advance warning, and as long as we don't rebase the master branch. Agreed. I've also thought of just merging master into the branch, but I'm still not quite proficient enough in git to judge how that will make later merging/cherry-picking into master easier or harder. I guess that merging into the branch now is probably made harder by the fact that we've cherry-picked from the branch into master? Anyway, if you want to rebase, fine with me. * Bob Friesenhahn wrote on Thu, Jan 08, 2009 at 09:17:37PM CET: > Someone needs to cut the next libtool Agreed, too; 2.2.8 soon would be good. A couple of small issues need looking at (esp. the aclocal.m4 messup reported by Akim). Any volunteers for the release? > so that we can bite the bullet and integrate your branch into > mainline. Agreed, too. Them bullets sure taste rather bitter, though. ;-) Cheers, Ralf
