Fink

Claus Atzenbeck wrote:
> Hi all,
>
> sed-4.1.5-11 fails to build:
>
> **************************************************
> [...]
> sed: 1: "install_sh=/sw/src/fink ...": command i expects \ followed by
> text
> sed: 1: "install_sh=/sw/src/fink ...": command i expects \ followed by
> text
> make
> make  all-recursive
> Making all in intl
> make[2]: *** No rule to make target `all'.  Stop.
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> ### execution of make failed, exit code 2
> [...]
> Failed: phase compiling: sed-4.1.5-11 failed
> **************************************************
>
> $ fink --version
> Package manager version: 0.26.0
> Distribution version: 0.8.1.rsync powerpc
>
> Mac OS 10.4.8
> XCode 2.4.1
>
> Cheers,
> Claus
>
>
>   
This appears to be a problem with the initial configuration (e.g. a 
missing build-depend, collision with a non-Fink version of something, etc.)

Can you post the output for the configuration phase of the build?

--akh--

On Wed, 27 Dec 2006, Alexander Hansen wrote:

> This appears to be a problem with the initial configuration (e.g. a missing
> build-depend, collision with a non-Fink version of something, etc.)
>
> Can you post the output for the configuration phase of the build?

Sure. See below. (Sorry for this rather long posting.)

**************************************************
[...]
gzip -dc /sw/src/sed-4.1.5.tar.gz | /sw/bin/tar -xf -  --no-same-owner --no-same-permissions
./configure --prefix=/sw --with-libiconv-prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --program-prefix=g
checking for a BSD-compatible install... /sw/bin/ginstall -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking for library containing strerror... none required
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for _LARGE_FILES value needed for large files... no
checking for long file names... yes
checking whether -lcP is needed... no
checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking for io.h... no
checking for limits.h... yes
checking for locale.h... yes
checking for stdarg.h... yes
checking for alloca.h... yes
checking for stddef.h... yes
checking for errno.h... yes
checking for wchar.h... yes
checking for wctype.h... yes
checking for sys/file.h... yes
checking for mcheck.h... no
checking for an ANSI C-conforming const... yes
checking for size_t... yes
checking for ssize_t... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for vprintf... yes
checking for _doprnt... no
checking for getline... no
checking for obstacks... no
checking whether mbrtowc and mbstate_t are properly declared... yes
checking for mbstate_t... yes
checking for strverscmp... no
checking for memchr... yes
checking for memcmp... yes
checking for memmove... yes
checking for strerror... yes
checking for mkstemp... yes
checking for isatty... yes
checking for bcopy... yes
checking for bzero... yes
checking for isascii... yes
checking for memcpy... yes
checking for memset... yes
checking for strchr... yes
checking for strtoul... yes
checking for popen... yes
checking for pathconf... yes
checking for isblank... yes
checking for fchown... yes
checking for fchmod... yes
checking for setlocale... yes
checking for wcrtomb... yes
checking for wcscoll... yes
checking for btowc... yes
checking how to build HTML documentation... with makeinfo
checking for msgfmt... /sw/bin/msgfmt
checking for gmsgfmt... /sw/bin/msgfmt
checking for xgettext... /sw/bin/xgettext
checking for msgmerge... /sw/bin/msgmerge
checking build system type... powerpc-apple-darwin8.8.0
checking host system type... powerpc-apple-darwin8.8.0
checking for inline... inline
checking for off_t... yes
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for getpagesize... yes
checking for working mmap... yes
checking whether we are using the GNU C Library 2.1 or newer... no
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for shared library run path origin... done
checking for iconv... yes
checking how to link with libiconv... /sw/lib/libiconv.dylib
checking argz.h usability... no
checking argz.h presence... no
checking for argz.h... no
checking for limits.h... (cached) yes
checking for locale.h... (cached) yes
checking nl_types.h usability... yes
checking nl_types.h presence... yes
checking for nl_types.h... yes
checking malloc.h usability... no
checking malloc.h presence... no
checking for malloc.h... no
checking for stddef.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for unistd.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking for feof_unlocked... yes
checking for fgets_unlocked... no
checking for getc_unlocked... yes
checking for getcwd... yes
checking for getegid... yes
checking for geteuid... yes
checking for getgid... yes
checking for getuid... yes
checking for mempcpy... no
checking for munmap... yes
checking for putenv... yes
checking for setenv... yes
checking for setlocale... (cached) yes
checking for stpcpy... yes
checking for strcasecmp... yes
checking for strdup... yes
checking for strtoul... (cached) yes
checking for tsearch... yes
checking for __argz_count... no
checking for __argz_stringify... no
checking for __argz_next... no
checking for iconv declaration...
         extern size_t iconv (iconv_t cd, const char * *inbuf, size_t *inbytesleft, char * *outbuf, size_t *outbytesleft);
checking for nl_langinfo and CODESET... yes
checking for LC_MESSAGES... yes
checking for bison... bison
checking version of bison... 2.3, ok
checking whether NLS is requested... yes
checking whether included gettext is requested... no
checking for GNU gettext in libc... no
checking for GNU gettext in libintl... yes
checking how to link with libintl... /sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lc
configure: creating ./config.status
config.status: creating bootstrap.sh
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating lib/Makefile
config.status: creating sed/Makefile
config.status: creating testsuite/Makefile
config.status: creating po/Makefile.in
config.status: creating intl/Makefile
config.status: creating config.h
config.status: linking ./lib/regex_.h to lib/regex.h
config.status: executing depfiles commands
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing gettext-fix commands
make
make  all-recursive
Making all in intl
### execution of make failed, exit code 2
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-sed-4.1.5-11
(Lese Datenbank ... 58357 Dateien und Verzeichnisse sind derzeit installiert.)
Entferne fink-buildlock-sed-4.1.5-11 ...
Failed: phase compiling: sed-4.1.5-11 failed
[...]
**************************************************

Claus Atzenbeck wrote:
> Hi all,
> 
> sed-4.1.5-11 fails to build:
> 
> **************************************************
> [...]
> sed: 1: "install_sh=/sw/src/fink ...": command i expects \ followed by
> text
> sed: 1: "install_sh=/sw/src/fink ...": command i expects \ followed by
> text
> make
> make  all-recursive
> Making all in intl
> make[2]: *** No rule to make target `all'.  Stop.
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
> ### execution of make failed, exit code 2

Same failure here. It seems this version of sed can be built only when 
gnu sed is already installed. The configure script uses a sed construct 
that doesn't work with Apple's /usr/bin/sed.

You can either install the ssed package or an older version of sed, like 
  the sed-4.0.5-1 from 10.4/stable (available from the bindist). Then 
upgrading to sed-4.1.5-11 will work.

-- 
Martin

On Wed, 27 Dec 2006, Martin Costabel wrote:

> You can either install the ssed package or an older version of sed, like  the
> sed-4.0.5-1 from 10.4/stable (available from the bindist). Then upgrading to
> sed-4.1.5-11 will work.

I had gsed installed. "sudo ln -s /sw/bin/gsed /sw/bin/sed" solved the
problem. Thanks for your hint.

Cheers,
Claus

Claus Atzenbeck wrote:
> On Wed, 27 Dec 2006, Martin Costabel wrote:
> 
>> You can either install the ssed package or an older version of sed, like  the
>> sed-4.0.5-1 from 10.4/stable (available from the bindist). Then upgrading to
>> sed-4.1.5-11 will work.
> 
> I had gsed installed. "sudo ln -s /sw/bin/gsed /sw/bin/sed" solved the
> problem. Thanks for your hint.

I'll CC the maintainer anyway. Not building without gnu sed installed is 
a bug in the sed package that needs fixing.

Here is the construct from configure that doesn't work with /usr/bin/sed:

   sed -e '/^mkinstalldirs *=/a\' \
       -e "install_sh=$install_sh" \
       -e 's/^mkinstalldirs *=.*/mkinstalldirs=$(MKINSTALLDIRS)/' \
       intl/Makefile > intl/Makefile.tmp

It is the /a that is not interpreted as it should.

-- 
Martin

On Wed, 27 Dec 2006, Martin Costabel wrote:

> I'll CC the maintainer anyway. Not building without gnu sed installed
> is a bug in the sed package that needs fixing.

A general question on fink's gsed: I had /sw/bin/gsed installed, but
apparently I needed a symbolic link /sw/bin/sed. Should I create it
anyway *manually*, such that calling sed prefers /sw/bin/sed (linking to
/sw/bin/gsed) instead of /usr/bin/sed? Or should this be done when
installing the package?

Updating fink's sed would also have worked for me if the configuration
explicitly would have called gsed (which is in /sw/bin) instead of sed
(which is in /usr/bin).

Cheers,
Claus

Claus Atzenbeck wrote:
> On Wed, 27 Dec 2006, Martin Costabel wrote:
> 
>> I'll CC the maintainer anyway. Not building without gnu sed installed
>> is a bug in the sed package that needs fixing.
> 
> A general question on fink's gsed: I had /sw/bin/gsed installed, but
> apparently I needed a symbolic link /sw/bin/sed. Should I create it
> anyway *manually*, such that calling sed prefers /sw/bin/sed (linking to
> /sw/bin/gsed) instead of /usr/bin/sed? Or should this be done when
> installing the package?

You should never do this by hand and never need to - except in an 
emergency as the present one. /sw/bin/gsed is installed by Fink's sed 
package. This package installs also the symlink /sw/bin/sed -> gsed, 
although in reality it is complicated by the use of update-alternatives. 
It is an indirect symlink

/sw/bin/sed -> /sw/etc/alternatives/sed -> /sw/bin/gsed

In case you have Fink's ssed package installed, the above symlink may 
point to /sw/bin/ssed instead.

If you have /sw/bin/gsed but not the symlink /sw/bin/sed, you have a 
broken incomplete installation of the sed package.

> Updating fink's sed would also have worked for me if the configuration
> explicitly would have called gsed (which is in /sw/bin) instead of sed
> (which is in /usr/bin).

As you may have noticed, the maintainer has now updated the sed package 
so that it builds both with gnu sed and with Apple's sed.

-- 
Martin

On Thu, 28 Dec 2006, Martin Costabel wrote:

> If you have /sw/bin/gsed but not the symlink /sw/bin/sed, you have a
> broken incomplete installation of the sed package.

I did:

fink selfupdate
fink remove sed
fink rebuild sed
fink install sed

which builds and installs sed-4.1.5-11, but "ls /sw/bin/sed" still does
not show any file. /sw/bin/gsed is installed though. Maybe it is not
meant to create a symbolic link from /sw/bin/sed to
/sw/etc/alternatives/sed.

/sw/etc/alternatives/sed exists, pointing to /sw/bin/gsed.
I probably should add it to my path.

Cheers,
Claus

Am 28.12.2006 um 07:50 schrieb Claus Atzenbeck:

> On Wed, 27 Dec 2006, Martin Costabel wrote:
>
>> I'll CC the maintainer anyway. Not building without gnu sed installed
>> is a bug in the sed package that needs fixing.
>
> A general question on fink's gsed: I had /sw/bin/gsed installed, but
> apparently I needed a symbolic link /sw/bin/sed. Should I create it
> anyway *manually*, such that calling sed prefers /sw/bin/sed  
> (linking to
> /sw/bin/gsed) instead of /usr/bin/sed? Or should this be done when
> installing the package?

Run
   fink info sed
and read it...

>
> Updating fink's sed would also have worked for me if the configuration
> explicitly would have called gsed (which is in /sw/bin) instead of sed
> (which is in /usr/bin).

For you, yes. But for everybody else, who does not (yet) *have* /sw/ 
bin/gsed, it wouldn't have worked.

Bye,
Max

Claus Atzenbeck wrote:
> On Thu, 28 Dec 2006, Martin Costabel wrote:
> 
>> If you have /sw/bin/gsed but not the symlink /sw/bin/sed, you have a
>> broken incomplete installation of the sed package.
> 
> I did:
> 
> fink selfupdate
> fink remove sed
> fink rebuild sed
> fink install sed
> 
> which builds and installs sed-4.1.5-11, but "ls /sw/bin/sed" still does
> not show any file. /sw/bin/gsed is installed though. Maybe it is not
> meant to create a symbolic link from /sw/bin/sed to
> /sw/etc/alternatives/sed.
> 
> /sw/etc/alternatives/sed exists, pointing to /sw/bin/gsed.

Maybe you should do what "fink info sed" says:

  Usage Notes:
   This program intalls as gsed, to use it as sed run
   'sudo update-alternatives --config sed'

I never had to do this and still had /sw/bin/sed; it was installed by 
the PostInstScript of the sed package. But then I never understood this 
update-alternatives business anyway.

-- 
Martin

On Thu, 28 Dec 2006, Martin Costabel wrote:

> Maybe you should do what "fink info sed" says:
>
>  Usage Notes:
>   This program intalls as gsed, to use it as sed run
>   'sudo update-alternatives --config sed'

Yes, I did this, but without success:

    [cirrus:~] admin$ sudo update-alternatives --config sed

    There is only 1 program which provides sed
    (/sw/bin/gsed). Nothing to configure.
    [cirrus:~] admin$ ls /sw/bin/sed
    ls: /sw/bin/sed: No such file or directory

This is true. /sw/bin only has gsed. The other one is in /usr/bin/.
My goal, however, was to get a symbolic link at /sw/bin/sed.

Anyway, it is not that important. I was just curious why it would not
work.

Thanks for all help I received.

Cheers,
Claus

Claus Atzenbeck wrote:
> Yes, I did this, but without success:
> 
>     [cirrus:~] admin$ sudo update-alternatives --config sed
> 
>     There is only 1 program which provides sed
>     (/sw/bin/gsed). Nothing to configure.
>     [cirrus:~] admin$ ls /sw/bin/sed
>     ls: /sw/bin/sed: No such file or directory

If you also had fink's ssed installed, you would have different results 
here.

> This is true. /sw/bin only has gsed. The other one is in /usr/bin/.
> My goal, however, was to get a symbolic link at /sw/bin/sed.

And "ls -al /sw/bin/sed" still yields nothing after running the 
update-alternatives commad?

(and in turn "ls -al /sw/etc/alternatives/sed" or "which sed")?

On Thu, 28 Dec 2006, Robert T Wyatt wrote:

> And "ls -al /sw/bin/sed" still yields nothing after running the
> update-alternatives commad?
>
> (and in turn "ls -al /sw/etc/alternatives/sed" or "which sed")?

No /sw/bin/sed, even after the update-alternatives command.
"which sed" still reports /usr/bin/sed.

After installing ssed, the update-alternatives command let me select
gsed or ssed, but neither option did create /sw/bin/sed.

It's not that important yet. I was just curious (and still am) why
/sw/bin/sed is not created.

Cheers,
Claus

Claus Atzenbeck wrote:
> On Thu, 28 Dec 2006, Robert T Wyatt wrote:
> 
>> And "ls -al /sw/bin/sed" still yields nothing after running the
>> update-alternatives commad?
>>
>> (and in turn "ls -al /sw/etc/alternatives/sed" or "which sed")?
> 
> No /sw/bin/sed, even after the update-alternatives command.
> "which sed" still reports /usr/bin/sed.
> 
> After installing ssed, the update-alternatives command let me select
> gsed or ssed, but neither option did create /sw/bin/sed.
> 
> It's not that important yet. I was just curious (and still am) why
> /sw/bin/sed is not created.

What about "fink reinstall sed"?

On Thu, 28 Dec 2006, Robert T Wyatt wrote:

> What about "fink reinstall sed"?

I've tried it before (and repeated it now), but also this does not
provide me with /sw/bin/sed.

Maybe it will show up magically in a future update. :)

Cheers,
Claus

I'm not sure where you are in the process.

Have you tried:
sudo apt-get install sed

I'm just wondering if you have some incompletely installed packages. It 
might suggest:

sudo apt-get -f install

You should do this if it is suggested (and it wouldn't hurt even if it 
didn't).

On Thu, 28 Dec 2006, Robert T Wyatt wrote:

> Have you tried:
> sudo apt-get install sed

Yes, right now. ;)
No /sw/bin/sed created.

> I'm just wondering if you have some incompletely installed packages. It might
> suggest:
>
> sudo apt-get -f install
>
> You should do this if it is suggested (and it wouldn't hurt even if it
> didn't).

Yes, I did now:

    sudo apt-get update ; sudo apt-get -f install

Errors have been reported and are solved now.
Then reinstalling sed, but still /sw/bin/sed doesn't show up.

Claus

So "fink list sed" doesn't show any installed versions? I thought you 
said that you also installed ssed--that doesn't show up either?
What does "ls -al /sw/etc/alternatives/sed" show?

On Thu, 28 Dec 2006, Robert T Wyatt wrote:

> So "fink list sed" doesn't show any installed versions? I thought you said
> that you also installed ssed--that doesn't show up either?

"fink list sed" showed gsed and ssed installed. Both were working.

> What does "ls -al /sw/etc/alternatives/sed" show?

It points to /sw/bin/gsed. This is correct. I was just wondering, why
there is no /sw/bin/sed pointing to /sw/etc/alternatives/sed.

Cheers,
Claus

Claus Atzenbeck wrote:
[]
>> What does "ls -al /sw/etc/alternatives/sed" show?
> 
> It points to /sw/bin/gsed. This is correct. I was just wondering, why
> there is no /sw/bin/sed pointing to /sw/etc/alternatives/sed.

I think I can smell the bug in update-alternatives that is responsible 
for this. Claus, just to confirm my suspicion, could you please try the 
following:

1. Remove the symlink /sw/bin/sed if you created it in the meantime.
2. Run
      update-alternatives --display sed | head -n1
    to confirm that "status is manual".
    If it says "status is auto", run
      sudo update-alternatives --config sed
    and choose 1 or 2.
3. Run "fink reinstall sed" and check if the symlink exists.
    I suspect it doesn't.
4. Run
      sudo update-alternatives --auto sed
5. Run "fink reinstall sed" and check if the symlink exists.
    I suspect it does exist now.
    It will actually have been created in step 4, but even if you
    remove it once more, it will come back in step 5, and it will
    stay with you henceforth.

If you confirm this, I'll take the discussion to fink-devel in order to 
find a solution.

-- 
Martin

On Fri, 29 Dec 2006, Martin Costabel wrote:

> I think I can smell the bug in update-alternatives that is responsible for
> this. Claus, just to confirm my suspicion, could you please try the following:

Sure.

> 1. Remove the symlink /sw/bin/sed if you created it in the meantime.

OK.

> 2. Run
>      update-alternatives --display sed | head -n1
>    to confirm that "status is manual".
>    If it says "status is auto", run
>      sudo update-alternatives --config sed
>    and choose 1 or 2.

Yes, status is manual. (BTW, I only have gsed installed.)

> 3. Run "fink reinstall sed" and check if the symlink exists.
>    I suspect it doesn't.

Correct, it doesn't exist.

> 4. Run
>      sudo update-alternatives --auto sed

Symlink /sw/bin/sed exists after calling this command.

> 5. Run "fink reinstall sed" and check if the symlink exists.
>    I suspect it does exist now.

Yes, symlink still exist.

>    It will actually have been created in step 4, but even if you
>    remove it once more, it will come back in step 5, and it will
>    stay with you henceforth.

I did a "fink remove sed" and the symlink was gone as well. After doing
a "fink install sed", the symlink has been created, as you expected.

Thanks for this hint!

> If you confirm this, I'll take the discussion to fink-devel in order
> to find a solution.

I guess that "update-alternatives --auto sed" should have been called
the first time I installed any sed via fink. Am I right?

Cheers,
Claus

Claus Atzenbeck wrote:
[]
> Yes, status is manual. (BTW, I only have gsed installed.)
> 
>> 3. Run "fink reinstall sed" and check if the symlink exists.
>>    I suspect it doesn't.
> 
> Correct, it doesn't exist.

The remaining question is how you got into this situation. You have 
repeatedly said that you "have gsed installed". I suppose by this you 
mean the Fink package "sed"; or do you have a package named "gsed"?

The only scenario I am seeing right now that explains how you got into 
the situation you found yourself in involves the following 3 steps:

1. You must have had, at some moment in time, both the sed and ssed 
packages installed.

2. Then you ran "update-alternatives --config sed" and chose one of the 
two alternatives.

3. Then you manually removed the symlink /sw/bin/sed.

Steps 2 and 3 can have occurred in reverse order, but up to now I don't 
see any other possibility to arrive where you have been. Or did you use 
other commands with update-alternatives that could explain the absence 
of the symlink?

What I am able to explain now is why the symlink was not recreated when 
it should have been, but not why it disappeared in the first place.

-- 
Martin

On Fri, 29 Dec 2006, Martin Costabel wrote:

> The remaining question is how you got into this situation. You have repeatedly
> said that you "have gsed installed". I suppose by this you mean the Fink
> package "sed"; or do you have a package named "gsed"?

Sorry for not being precise. Certainly, I mean fink's sed package.

> 1. You must have had, at some moment in time, both the sed and ssed packages
> installed.
>
> 2. Then you ran "update-alternatives --config sed" and chose one of the two
> alternatives.
>
> 3. Then you manually removed the symlink /sw/bin/sed.

Possibly, but I am not aware of that. I also would be very surprised if
I used update-alternatives before. And I am quite sure that I never
removed any (working) symlink in /sw/bin/. In case I do, I always check
if they point to an existing file or directory.

I moved from one Mac to another two years ago using Apple's assistant.
This also copied the complete /sw directory. Possibly something went
wrong there.

Again, thanks for clarifying this problem.

Cheers,
Claus