Re[7]: [Gc]: Dependency tracking for configuration macros

Ivan Maidanski ivmai at mail.ru
Fri Sep 25 23:10:53 PDT 2009


Hi!

Petter Urkedal <urkedal at nbi.dk> wrote:
> On 2009-09-26, Ivan Maidanski wrote:
> > autoreconf works correctly but configure failed with error "can't make a symbolic link" (that's because I've placed "bdwgc" on NTFS drive) and make, then, failed too.

I'm sorry, this was on FAT (which I use for RAM disk), NTFS should support "ln".

> > Everything works correctly on a native Linux FS.
> 
> Do you think that may be the libatomic_ops-related "ln" commands on
> lines 718--729?

Yes.

> If that's the only ones, we could probably fix it after
> the version-number is dropped from the directory.  (That is a pending
> change as far as I remember.)  For a workaround you could rename/copy
> the libatomic_ops directory and copy the two files atomic_ops.c and
> atomic_ops_sysdeps.S into the top-level directory, so that the "ln"
> commands are skipped.

As a workaround, I copied this to LinuxFS (so, this would require additional "cp" on each regenerate).

Hans wrote:
> I'm with Petter on this.  If it's easy, great.
> 
> If it involves getting rid of the version number from the atomic_ops directory, even better, since that was on my list anyway.  Libatomic_ops should either be handled as a separate package, or should just use GC version numbers.  And I think the former option requires more work for which we're currently lacking volunteers.

If I understand right, the latter case is to cut "-1.2" for "libatomic_ops" (in CVS and tar-ball) and replace such things as /Ilibatomic_ops-$(AO_VERSION) to /Ilibatomic_ops (and remove AO_VERSION assignment). For me, this is the prefered way. But the problem is CVS - could we rename a folder in a repo (preserving the CVS log)?

If the final decesion would be to cut "-1.2", I'll prepare the patch for makefiles (for other building scripts, let this be on Petter).

Bye.


More information about the Gc mailing list