unfortunately, i've attempted such rebuilds several times, not only though the steps you suggested, but from cvs updates *and* complete cvs checkouts (that is, delete all files from my computer and checkout from scratch). no dice.

i know there's a way to get this to work if other people are building without issue. i just don't have the ability to modify the makefile or somesuch voodoo without seriously causing some problems (read: i'm a noob).

i appreciate your swift reply. hopefully the resolution to this will help some other poor unfortunate soul, too.

--seth

Bryce Harrington wrote:

Have you tried doing a make clean and rebuilding everything from autogen.sh?

Bryce

On Sat, Aug 06, 2005 at 06:25:50PM -0700, Seth Brutzman wrote:

...

i've been attempting to build inkscape from cvs, using source from 2005.08.06. i ran autogen.sh, then ./configure -enable-perl --enable-python --with-xft. all of that went smoothly enough (perl and python were skipped), but i've run across the recurring error below on every make i've initiated.

i'm not quite sure whats going on here -- is it an issue with my config or am i missing some library/file? admittedly, i'm not overly experienced with compiling from cvs, but in the past have had no problems with building the tarballs.

if it helps at all, here are some vitals: debian GNU/linux i686 automake 1.9.4 gcc 3.3.5 (debian) latest libtools, etc

thanks for your help! --seth

/* make output and exit errors */ make all-recursive make[1]: Entering directory `/usr/src/inkscape' Making all in src make[2]: Entering directory `/usr/src/inkscape/src' gcc -g -O2 -c libnr/have_mmx.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.S rm -f libnr/libnr.a ar cru libnr/libnr.a libnr/nr-blit.o libnr/nr-compose-transform.o libnr/nr-compose.o libnr/nr-gradient.o libnr/nr-matrix-div.o libnr/nr-matrix-fns.o libnr/nr-matrix-rotate-ops.o libnr/nr-matrix-scale-ops.o libnr/nr-matrix-translate-ops.o libnr/nr-matrix.o libnr/nr-object.o libnr/nr-path.o libnr/nr-pixblock-line.o libnr/nr-pixblock-pattern.o libnr/nr-pixblock-pixel.o libnr/nr-pixblock.o libnr/nr-point-fns.o libnr/nr-rect-l.o libnr/nr-rect.o libnr/nr-rotate-fns.o libnr/nr-rotate-matrix-ops.o libnr/nr-scale-matrix-ops.o libnr/nr-scale-translate-ops.o libnr/nr-svp-render.o libnr/nr-svp.o libnr/nr-translate-matrix-ops.o libnr/nr-translate-scale-ops.o libnr/nr-translate-rotate-ops.o libnr/nr-types.o libnr/nr-values.o libnr/have_mmx.o libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.o libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.o make[2]: Leaving directory `/usr/src/inkscape/src' make[1]: Leaving directory `/usr/src/inkscape' ar: libnr/have_mmx.o: No such file or directory make[2]: *** [libnr/libnr.a] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

---

SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

i spent quite a while searching through lists and bug reports, trying to find another instance of this problem, both to find a solution and to ensure that i won't be duping a bug. haven't come across one yet.

i went ahead and compiled with --disable-mmx as Alexandre suggested, and it built flawlessly. this, however, seems a poor workaround as i'm running a p4, rather than an amd, so mmx should be a given.

here's my new question: how much of a performance difference is there between mmx enabled and disabled builds? and, should i report this as a genuine bug, or let it go since it's an isolated compile error rather than a program error?

either way, i'm still going to try and find the problem.

--seth

Bryce Harrington wrote:

Okay, thanks, that rules out that class of issues.

Well, I'm not sure what the problem is, but I can give you some small bits of generic background info that might help you pinpoint it.

The name of the file, have_mmx.o, is Inkscape's MMX assembler code, for optimizing certain low level operations. If I remember right, its compilation is controlled such that if MMX is not available, it won't compile the code.

My guess would be that this control code is mussed up for some reason on your system. I might guess that you're on an architecture that for some reason is not getting detected right, or that something is conflicting.

Have you browsed through the bug tracker to see if anyone else has reported a similar problem? I don't recall ever hearing anyone report this particular problem before, but it's possible someone else has run into it.

Bryce

On Sat, Aug 06, 2005 at 07:52:31PM -0700, Seth Brutzman wrote:

...

unfortunately, i've attempted such rebuilds several times, not only though the steps you suggested, but from cvs updates *and* complete cvs checkouts (that is, delete all files from my computer and checkout from scratch). no dice.

i know there's a way to get this to work if other people are building without issue. i just don't have the ability to modify the makefile or somesuch voodoo without seriously causing some problems (read: i'm a noob).

i appreciate your swift reply. hopefully the resolution to this will help some other poor unfortunate soul, too.

--seth

Bryce Harrington wrote:

...

Have you tried doing a make clean and rebuilding everything from autogen.sh?

Bryce

On Sat, Aug 06, 2005 at 06:25:50PM -0700, Seth Brutzman wrote:

...

i've been attempting to build inkscape from cvs, using source from 2005.08.06. i ran autogen.sh, then ./configure -enable-perl --enable-python --with-xft. all of that went smoothly enough (perl and python were skipped), but i've run across the recurring error below on every make i've initiated.

i'm not quite sure whats going on here -- is it an issue with my config or am i missing some library/file? admittedly, i'm not overly experienced with compiling from cvs, but in the past have had no problems with building the tarballs.

if it helps at all, here are some vitals: debian GNU/linux i686 automake 1.9.4 gcc 3.3.5 (debian) latest libtools, etc

thanks for your help! --seth

/* make output and exit errors */ make all-recursive make[1]: Entering directory `/usr/src/inkscape' Making all in src make[2]: Entering directory `/usr/src/inkscape/src' gcc -g -O2 -c libnr/have_mmx.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.S gcc -g -O2 -c libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.S rm -f libnr/libnr.a ar cru libnr/libnr.a libnr/nr-blit.o libnr/nr-compose-transform.o libnr/nr-compose.o libnr/nr-gradient.o libnr/nr-matrix-div.o libnr/nr-matrix-fns.o libnr/nr-matrix-rotate-ops.o libnr/nr-matrix-scale-ops.o libnr/nr-matrix-translate-ops.o libnr/nr-matrix.o libnr/nr-object.o libnr/nr-path.o libnr/nr-pixblock-line.o libnr/nr-pixblock-pattern.o libnr/nr-pixblock-pixel.o libnr/nr-pixblock.o libnr/nr-point-fns.o libnr/nr-rect-l.o libnr/nr-rect.o libnr/nr-rotate-fns.o libnr/nr-rotate-matrix-ops.o libnr/nr-scale-matrix-ops.o libnr/nr-scale-translate-ops.o libnr/nr-svp-render.o libnr/nr-svp.o libnr/nr-translate-matrix-ops.o libnr/nr-translate-scale-ops.o libnr/nr-translate-rotate-ops.o libnr/nr-types.o libnr/nr-values.o libnr/have_mmx.o libnr/nr_mmx_R8G8B8A8_P_EMPTY_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_A8_RGBAP.o libnr/nr_mmx_R8G8B8A8_P_R8G8B8A8_P_R8G8B8A8_N_TRANSFORM.o libnr/nr_mmx_R8G8B8_R8G8B8_R8G8B8A8_P.o make[2]: Leaving directory `/usr/src/inkscape/src' make[1]: Leaving directory `/usr/src/inkscape' ar: libnr/have_mmx.o: No such file or directory make[2]: *** [libnr/libnr.a] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2

---

SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

---

SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

submitted as bug #1253415

--seth

Bryce Harrington wrote:

On Sat, Aug 06, 2005 at 09:27:06PM -0700, Seth Brutzman wrote:

...

i spent quite a while searching through lists and bug reports, trying to find another instance of this problem, both to find a solution and to ensure that i won't be duping a bug. haven't come across one yet.

Very good, thanks.

...

i went ahead and compiled with --disable-mmx as Alexandre suggested, and it built flawlessly. this, however, seems a poor workaround as i'm running a p4, rather than an amd, so mmx should be a given.

Cool. Yeah like I mentioned, we have control code to disable the mmx in cases where it causes problems. It's unusual for there be problems with this - your case is the first I've personally heard about. You've got a good point that it's unusual. I (and of course many others) have compiled on p4s, so you've got an "interesting" case as they say.

...

here's my new question: how much of a performance difference is there between mmx enabled and disabled builds? and, should i report this as a genuine bug, or let it go since it's an isolated compile error rather than a program error?

This is a good question. My guess is that it makes a difference, but I think this is definitely worth testing; I've been curious about it myself.

It would be definitely be worth listing in the bug tracker, including your work-around, both for people who might run into it in the future, and for establishing a thread in which the root cause can be explored.

...

either way, i'm still going to try and find the problem.

Excellent, thanks. Build issues are annoying and the fewer of them (even unusual corner cases), the better off we'll all be in the long haul.

Bryce

---

SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

interesting... so i just went and checked the @TOPSRCDIR@/src/ directory, and lo! i have found have_mmx.so. this is all good and fine, but according to make, it should be in @TOPSRCDIR@/src/libnr/. here's a new question: is this a generated file (do i have to hack the makefile to fix this), or is this a static file that i can just slap in the correct directory before running make?

either way, though, there's an error in the build process somewhere (either in the scripts or in the directory structure).

--seth

Bob Jamison wrote:

I guess this is the obvious question.... Does the have_mmx.o file exist in the source tree? Maybe this is a more subtle problem that is specific to your system or Gnu toolchain. Maybe it's just lost, or something. Note that in your paste, the compiler had no errors during generating the .o's from the .S's. It merely couldn't find that one while collecting it up into a library.

Bob

On Wed, Aug 10, 2005 at 03:10:36PM -0700, Kees Cook wrote:

On Sat, Aug 06, 2005 at 11:09:21PM -0700, Seth Brutzman wrote:

...

either way, though, there's an error in the build process somewhere (either in the scripts or in the directory structure).

This is a known bug in automake1.9 unfortunately. (I though we rejected automake 1.9 in autogen.sh?) If you use am 1.7 or 1.8, inkscape should build fine. :(

http://sourceforge.net/tracker/index.php?func=detail&aid=1056633&gro...

Seth, can you report what version of automake you're using? Kees' hypothesis suggests that you're using 1.9.

Do you have the ability to try out other versions of automake? If he is correct (as he usually is), you should find that automake 1.8 compiles correctly. It also suggests that there is breakage in our build system's detection of automake versions.

Bryce

I can go ahead and grab/compile automake 1.8.x and give it a go. I have a feeling that the build system is a bit messed up as I'm using some items from Debian packages and some self-compiled. Invariably this causes problems, but attempting to purge my system of the Debian versions makes APT want to uninstall my entire system (everything depends on gcc!).

Looks like it's time to roll my own distro.

I'll post the results when I run an automake 1.8 compile.

The hackers on this list obviously know what they're doing :)

I went ahead and grabbed automake 1.8.5, wiped my sandbox to get rid of the files that I moved around, and compiled Inkscape from CVS without a hitch. Thanks to everyone that helped out with this! Inkscape has a fantastic community!

So, just for the record, automake 1.9.x worked for me overall except that any mmx optimizations would cause make to error due to the misplacing of .o files. I was able to got around the problem in three ways:

1) Compile Inkscape without mmx optimization (not my favorite solution) 2) Manually move all *_mmx*.o files from @TOPSRCDIR@/src/ to @TOPSRCDIR@/src/libnr/ when make fails (not difficult or particularly time consuming, but annoying nonetheless) 3) Regress to 1.8 series of automake (the simplest and most reliable in the end, but it's always a shame when tools aren't backwards compatible)

I wish I knew why automake is the buggy link in the chain, or why in only has issues with mmx support. Don't hold me to this, as I'm not all that familiar with the tool (and I only have limited programming experience), but I'll try compiling with automake 1.9 again and examining the results. If I come up with anything of merit, I'll post it.

Again, thanks for all the help, guys. I love Inkscape and I'm looking forward to doing more bug hunting and whatever else I may for the project.

-- Seth Brutzman deadlyhead@...952...

On Sat, Aug 13, 2005 at 11:59:45PM -0700, Seth Brutzman wrote:

I went ahead and grabbed automake 1.8.5, wiped my sandbox to get rid of the files that I moved around, and compiled Inkscape from CVS without a hitch. Thanks to everyone that helped out with this! Inkscape has a fantastic community!

3. Regress to 1.8 series of automake (the simplest and most reliable

in the end, but it's always a shame when tools aren't backwards compatible)

I wish I knew why automake is the buggy link in the chain, or why in only has issues with mmx support. Don't hold me to this, as I'm not all that familiar with the tool (and I only have limited programming experience), but I'll try compiling with automake 1.9 again and examining the results. If I come up with anything of merit, I'll post it.

Excellent!

Could you do one additional thing as part of wrapping this up - can you make sure this bug is filed upstream, so that the automake folks are aware of it, and so that hopefully future users won't encounter the issue? (Chances are good they already know about it, but it's worth it to check.)

Bryce

On Sun, Aug 14, 2005 at 01:22:46PM -0700, Seth Brutzman wrote:

I filed a bug report with the automake team (a really, _really_ long URL):

I constructed a slightly shorter one:

http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake&pr=472&a...

Seems like gnatsweb should have a saner way to link to bugs. :)

Great write-up. I'm trying to figure out how to add myself as a CC now... hmpf

Seth Brutzman wrote:

I wish I knew why automake is the buggy link in the chain, or why in only has issues with mmx support. Don't hold me to this, as I'm not all that familiar with the tool (and I only have limited programming experience), but I'll try compiling with automake 1.9 again and examining the results. If I come up with anything of merit, I'll post it.

I got a reply from the automake team!

Hello,

regarding the problem:

...

...

gcc -g -O2 -c libnr/have_mmx.S [...] ar cru [...] libnr/have_mmx.o [...] ar: libnr/have_mmx.o: No such file or directory

The problem could be fixed by adding option -o libnr/have_mmx.o to the gcc.

Attached please find a patch, which should do this (there are two versions, for 1.9 and for CVS HEAD). The patch is not tested.

(It should be possible to apply the 1.9 patch directly to the installed /usr/bin/automake script.)

BTW: *.S will mean _preprocessed_ assembler in automake-1.10. So if this is not your case, you should rather use *.s for asm sources.

HTH, Stepan Kasal

Honestly, I don't really know what all of this means, as I'm still new to all the wonders of compile scripts, etc. I've included the patches he sent, though I'm currently learning how to apply them (yeah, I'm a true neophyte. I can read code and I'm somewhat proficient in some languages, but I have no experience in real world development practices). Hopefully they'll end up on the mailing list like a normal attachment.

So I'll give this a go.

-- Seth Brutzman deadlyhead@...952...

Kees Cook wrote:

If you're root and you do: cd /usr/bin patch -p0 automake < /path/to/this/patch

I think it'll apply and you can see if using automake 1.9 works then. If so, let them know the patch worked for you. :)

The patch worked! I patched up my install of automake 1.9.6, went through and compiled Inkscape from a CVS update without a hitch!

Thanks for enlightening me, Kees. That makes, what, three times you've steered me in the right direction this thread? ;)

I'm off to thank a Mr. Kasal with the automake team for the patch and bid him a job well done.

-- Seth Brutzman deadlyhead@...952...

On Thu, 2005-08-18 at 04:48 -0700, Bryce Harrington wrote:

On Mon, Aug 15, 2005 at 01:32:45PM -0700, Kees Cook wrote:

...

On Mon, Aug 15, 2005 at 12:10:52PM -0700, Seth Brutzman wrote:

...

...

BTW: *.S will mean _preprocessed_ assembler in automake-1.10. So if this is not your case, you should rather use *.s for asm sources.

Whoever wrote the MMX code will have to answer this. It just means inkscape may need to rename these files in automake 1.10. No big deal.

These files were written by Lauris. Mental may be able to answer it, but I suspect the right approach is to go ahead and rename the files, and keep an eye out for any issues that crop up.

So long as the files don't contain any preprocessor macros (I don't believe they do), renaming them should be fine.

-mental

On Tue, Aug 09, 2005 at 10:27:33AM -0700, Seth Brutzman wrote:

Alright, I've been tracking this with bug #1253415 as I find out about more about it, and I've come to understand the following:

--When the source is being organized for compilation (I'm not sure, is this autogen.sh or configure, or is there any such setup performed?), all *.o files related to mmx support end up in $topsrcdir/src/ rather than $topsrcdir/src/libnr/ where they belong --To compile with mmx support, moving all the files to the appropriate directory is necessary. #mv $topsrcdir/src/*_mmx*.o $topsrcdir/src/libnr/ accomplishes this --Continue build normally

It was simple enough, once I found all the hangup files. What I don't understand, though, is where does this program originate? Is it configure? autogen.sh? Or is the problem all the way back to where the files are in the source tree?

Just thought I'd shed some more light on this.

Hmm, interesting. This suggests it is a build system issue.

My guess is that in the Makefile, the definition for turning .S files in to .o files has an error.

Look in your Makefile, for something that looks like this:

.S.o: $(CCASCOMPILE) -c `test -f '$<' || echo '$(srcdir)/'`$<

and

libnr/have_mmx.o: libnr/have_mmx.S $(CCAS) $(AM_CCASFLAGS) $(CCASFLAGS) -c -o libnr/have_mmx.o `test -f 'libnr/have_mmx.S' || echo '$(srcdir)/'`libnr/have_mmx.S

etc.

Note how it specifies that have_mmx.o is directed to output (-o) into libnr/have_mmx.o. I am guessing that perhaps on your system it may be outputting to have_mmx.o directly. Or something else similarly wacky.

Anyway, see what's in your Makefile and if it corresponds to what I have in mind, and we'll go from there.

Bryce