Re: Build/Makefile question
I should have mentioned sooner, but thanks, that fixed my problem! -- Caroline cmt...@google.com On Mon, Oct 29, 2012 at 10:34 AM, Ian Lance Taylor i...@google.com wrote: On Mon, Oct 29, 2012 at 10:24 AM, Caroline Tice cmt...@google.com wrote: Actually, I did have to edit the Makefile.in slightly. When I generate it with automake, it automatically adds the lines: libvtv_init_la_LIBADD = libvtv_init_la_SOURCES = libvtv_init.c libvtv_init_la_OBJECTS = libvtv_init.lo libvtv_stubs_la_LIBADD = libvtv_stubs_la_SOURCES = libvtv_stubs.c libvtv_stubs_la_OBJECTS = libvtv_stubs.lo as well as the lines: SOURCES = $(libsupc___la_SOURCES) $(libsupc__convenience_la_SOURCES) \ libvtv_init.c libvtv_stubs.c I don't know where it's getting those source file names, but they're wrong. I went in and removed the lib prefix from them, but I hadn't noticed that it had made them .c files instead of .cc files. If you know how to fix the .am file so that it doesn't generate these bogus wrong source files in the .in file, I would appreciate your sharing with me... Hmmm, never, ever, edit the Makefile.in file. And if you do edit it, for goodness sakes tell us. But never edit it in the first place. libvtv_init_la_SOURCES = libvtv_init.c automake came up with that because it is the default SOURCES for a library. It means that you didn't define the required SOURCES variable. You can see the name of that SOURCE variable from the line that automake introduced: it's libvt_init_la_SOURCES. Ian
Re: Build/Makefile question
Hi, On Sat, 27 Oct 2012, Ian Lance Taylor wrote: On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice cmt...@google.com wrote: Ian Tayler (in private communication) asked that I get the part of the build log that shows the .so and .a files being built and send it to the list. Here it is. I see the problem. libstdc++/libsupc++/Makefile.am overrides the default CXXLINK to invoke libtool with --tag disable-shared. Your new shared libraries have only C input files, so they are being linked with CXXLINK, they are being linked with LINK. You need to override the default value of LINK. Actually her Makefile.am contains C++ sources: ! vtv_init_sources = \ ! vtv_init.cc ! ! vtv_stubs_sources = \ ! vtv_stubs.cc which should be enough to make it use CXXLINK, but her Makefile.in contains: + libvtv_init_la_LIBADD = + libvtv_init_la_SOURCES = vtv_init.c + libvtv_init_la_OBJECTS = vtv_init.lo + libvtv_stubs_la_LIBADD = + libvtv_stubs_la_SOURCES = vtv_stubs.c + libvtv_stubs_la_OBJECTS = vtv_stubs.lo ... ! SOURCES = $(libsupc___la_SOURCES) $(libsupc__convenience_la_SOURCES) \ ! libvtv_init.c libvtv_stubs.c ... but then still ... ! vtv_init_sources = \ ! vtv_init.cc ! ! vtv_stubs_sources = \ ! vtv_stubs.cc So, the first hunk of Makefile.in contains references to .c files. Caroline: did you edit Makefile.in yourself? Otherwise I don't see how this file could have been generated by automake with this inconsistent use of .c/.cc. Or maybe you have still .c sources lying around in your source tree? Ciao, Michael.
Re: Build/Makefile question
On Mon, Oct 29, 2012 at 7:55 AM, Michael Matz m...@suse.de wrote: Hi, On Sat, 27 Oct 2012, Ian Lance Taylor wrote: On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice cmt...@google.com wrote: Ian Tayler (in private communication) asked that I get the part of the build log that shows the .so and .a files being built and send it to the list. Here it is. I see the problem. libstdc++/libsupc++/Makefile.am overrides the default CXXLINK to invoke libtool with --tag disable-shared. Your new shared libraries have only C input files, so they are being linked with CXXLINK, they are being linked with LINK. You need to override the default value of LINK. Actually her Makefile.am contains C++ sources: ! vtv_init_sources = \ ! vtv_init.cc ! ! vtv_stubs_sources = \ ! vtv_stubs.cc which should be enough to make it use CXXLINK, but her Makefile.in contains: + libvtv_init_la_LIBADD = + libvtv_init_la_SOURCES = vtv_init.c + libvtv_init_la_OBJECTS = vtv_init.lo + libvtv_stubs_la_LIBADD = + libvtv_stubs_la_SOURCES = vtv_stubs.c + libvtv_stubs_la_OBJECTS = vtv_stubs.lo ... ! SOURCES = $(libsupc___la_SOURCES) $(libsupc__convenience_la_SOURCES) \ ! libvtv_init.c libvtv_stubs.c ... but then still ... ! vtv_init_sources = \ ! vtv_init.cc ! ! vtv_stubs_sources = \ ! vtv_stubs.cc So, the first hunk of Makefile.in contains references to .c files. Caroline: did you edit Makefile.in yourself? Otherwise I don't see how this file could have been generated by automake with this inconsistent use of .c/.cc. Or maybe you have still .c sources lying around in your source tree? Actually, I did have to edit the Makefile.in slightly. When I generate it with automake, it automatically adds the lines: libvtv_init_la_LIBADD = libvtv_init_la_SOURCES = libvtv_init.c libvtv_init_la_OBJECTS = libvtv_init.lo libvtv_stubs_la_LIBADD = libvtv_stubs_la_SOURCES = libvtv_stubs.c libvtv_stubs_la_OBJECTS = libvtv_stubs.lo as well as the lines: SOURCES = $(libsupc___la_SOURCES) $(libsupc__convenience_la_SOURCES) \ libvtv_init.c libvtv_stubs.c I don't know where it's getting those source file names, but they're wrong. I went in and removed the lib prefix from them, but I hadn't noticed that it had made them .c files instead of .cc files. If you know how to fix the .am file so that it doesn't generate these bogus wrong source files in the .in file, I would appreciate your sharing with me... -- Caroline cmt...@google.com Ciao, Michael.
Re: Build/Makefile question
On Mon, Oct 29, 2012 at 10:24 AM, Caroline Tice cmt...@google.com wrote: Actually, I did have to edit the Makefile.in slightly. When I generate it with automake, it automatically adds the lines: libvtv_init_la_LIBADD = libvtv_init_la_SOURCES = libvtv_init.c libvtv_init_la_OBJECTS = libvtv_init.lo libvtv_stubs_la_LIBADD = libvtv_stubs_la_SOURCES = libvtv_stubs.c libvtv_stubs_la_OBJECTS = libvtv_stubs.lo as well as the lines: SOURCES = $(libsupc___la_SOURCES) $(libsupc__convenience_la_SOURCES) \ libvtv_init.c libvtv_stubs.c I don't know where it's getting those source file names, but they're wrong. I went in and removed the lib prefix from them, but I hadn't noticed that it had made them .c files instead of .cc files. If you know how to fix the .am file so that it doesn't generate these bogus wrong source files in the .in file, I would appreciate your sharing with me... Hmmm, never, ever, edit the Makefile.in file. And if you do edit it, for goodness sakes tell us. But never edit it in the first place. libvtv_init_la_SOURCES = libvtv_init.c automake came up with that because it is the default SOURCES for a library. It means that you didn't define the required SOURCES variable. You can see the name of that SOURCE variable from the line that automake introduced: it's libvt_init_la_SOURCES. Ian
Re: Build/Makefile question
Ian Tayler (in private communication) asked that I get the part of the build log that shows the .so and .a files being built and send it to the list. Here it is. -- Caroline Tice cmt...@google.com /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -shared-libgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc -nostdinc++\ -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/loca\ l/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m\ 32 -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-v3/../libgcc -I/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/usr/local\ /google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-v3/libsupc++ -prefer-pic -D_GLIBCXX_SHARED -Wall -Wextra -Wwrit\ e-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=vtv_init.lo -g -O0 -D_GNU_SOURCE -m32 -Wl,-L../libsupc++/.libs -Wl,--wh\ ole-archive,-lvtv_init,--no-whole-archive -fvtable-verify=std -Wno-error -c ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc libtool: compile: /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -shared-libgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc -nostdinc++ -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-\ unknown-linux-gnu/32/libstdc++-v3/src -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86\ _64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-\ v3/../libgcc -I/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-\ gnu/32/libstdc++-v3/include -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -f\ function-sections -fdata-sections -frandom-seed=vtv_init.lo -g -O0 -D_GNU_SOURCE -m32 -Wl,-L../libsupc++/.libs -Wl,--whole-archive,-lvtv_init,--no-whole-archive -fvtable-verify=std -Wno-er\ ror -c ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o vtv_init.o ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc:49:54: warning: constructor priorities from 0 to 100 are reserved for the implementation [enabled by default] void __VLTunprotect() __attribute__((constructor(98))); ^ ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc:59:53: warning: constructor priorities from 0 to 100 are reserved for the implementation [enabled by default] void __VLTprotect() __attribute__((constructor(100))); ^ /bin/sh ../libtool --tag=CC --mode=link /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/\ local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -g -O0 -m32 -m32 -o libvtv_init.l\ a -rpath /usr/local/lib/../lib32 vtv_init.lo libtool: link: /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-\ gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -shared-m32 -m32 -m32 -Wl,-soname -Wl,libvtv_init.so.0 -o\ .libs/libvtv_init.so.0.0.0 libtool: link: (cd .libs rm -f libvtv_init.so.0 ln -s libvtv_init.so.0.0.0 libvtv_init.so.0) libtool: link: (cd .libs rm -f libvtv_init.so ln -s libvtv_init.so.0.0.0 libvtv_init.so) libtool: link: ar rc .libs/libvtv_init.a vtv_init.o libtool: link: ranlib .libs/libvtv_init.a libtool: link: ( cd .libs rm -f libvtv_init.la ln -s ../libvtv_init.la libvtv_init.la ) /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -shared-libgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc -nostdinc++\ -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/loca\ l/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include
Re: Build/Makefile question
On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice cmt...@google.com wrote: Ian Tayler (in private communication) asked that I get the part of the build log that shows the .so and .a files being built and send it to the list. Here it is. I see the problem. libstdc++/libsupc++/Makefile.am overrides the default CXXLINK to invoke libtool with --tag disable-shared. Your new shared libraries have only C input files, so they are being linked with CXXLINK, they are being linked with LINK. You need to override the default value of LINK. Ian
Re: Build/Makefile question
On Fri, Oct 26, 2012 at 10:58 AM, Caroline Tice cmt...@google.com wrote: I am working on a patch (which I hope to be able to submit in the next few days), and I have run into a snag that I am hoping someone can help me with. As part of this patch, I am trying to build two new *.a (static archive) libraries in libstdc++-v3/libsupc++. I have modified Makefile.am and rebuilt Makefile.in in libsupc++ to do this. I had this working just fine on GCC 4.6.3, but when I try to apply the changes to GCC ToT, I find that something in the build system seems to have changed: Not only is it building the two static archive libraries, it is ALSO then building two dynamic shared libraries (*.so files), which I do NOT want. And even worse, it's putting the wrong stuff into the .so files. I have not been able to find/isolate the code that is telling GCC to go build the .so files. As I said, this worked for me in GCC 4.6.3. Does anybody know what might be going wrong or where/how to fix this? Help, please?? Kind of hard to say without seeing the patch. Look at the build log, and make sure that libtool is being invoked with --tag disable-shared. That should be all that is required. Ian
Re: Build/Makefile question
Ok, here are the patches for the Makefile.am and Makefile.in files. I am also having trouble with the following issue: I need to make sure that one of the new libraries is linked in with libstdc++ when libstdc++ gets built. I have not been able to successfully figure out where exactly is the command that builds links libstdc++.so.* (yes I've looked at the build; it's being built with libtool somewhere, somehow, and no matter where/how I specify the link flag to link in my new library, the libtool link command is not picking it up). -- Caroline Tice cmt...@google.com On Fri, Oct 26, 2012 at 2:28 PM, Ian Lance Taylor i...@google.com wrote: On Fri, Oct 26, 2012 at 10:58 AM, Caroline Tice cmt...@google.com wrote: I am working on a patch (which I hope to be able to submit in the next few days), and I have run into a snag that I am hoping someone can help me with. As part of this patch, I am trying to build two new *.a (static archive) libraries in libstdc++-v3/libsupc++. I have modified Makefile.am and rebuilt Makefile.in in libsupc++ to do this. I had this working just fine on GCC 4.6.3, but when I try to apply the changes to GCC ToT, I find that something in the build system seems to have changed: Not only is it building the two static archive libraries, it is ALSO then building two dynamic shared libraries (*.so files), which I do NOT want. And even worse, it's putting the wrong stuff into the .so files. I have not been able to find/isolate the code that is telling GCC to go build the .so files. As I said, this worked for me in GCC 4.6.3. Does anybody know what might be going wrong or where/how to fix this? Help, please?? Kind of hard to say without seeing the patch. Look at the build log, and make sure that libtool is being invoked with --tag disable-shared. That should be all that is required. Ian Makefile.am.diff Description: Binary data Makefile.in.diff Description: Binary data
Re: Build/Makefile question
On Fri, Oct 26, 2012 at 3:25 PM, Caroline Tice cmt...@google.com wrote: Ok, here are the patches for the Makefile.am and Makefile.in files. I am also having trouble with the following issue: I need to make sure that one of the new libraries is linked in with libstdc++ when libstdc++ gets built. I have not been able to successfully figure out where exactly is the command that builds links libstdc++.so.* (yes I've looked at the build; it's being built with libtool somewhere, somehow, and no matter where/how I specify the link flag to link in my new library, the libtool link command is not picking it up). Hmmm, your patch is pretty simple. You say that this is causing your new libraries to be built both as .a and .so files? I guess I have no explanation. What does the output of make look like when building libsupc++? The rule for building libstdc++ itself is in libstdc++/src/Makefile.am. Note how it links against $(top_builddir)/libsupc++/libsupc++convenience.la . Ian
