Перехватить ВЕСЬ свой stdout, в т.ч. выводимый чужими подлинкованными либами.

Убери это и озвучь целиком задачу. Не забудь уточнить, какие средства можно использовать и можешь ли ты настроить перенвправление до инициализации этих библиотек.

Эээ ну делаешь пайп, потом fork и exec самого себя с каким-то ключиком. Чайлд делает то что нужно делать, парент читает из пайпа выхлоп и делает что надо делать с выхлопом

Никаких fork/exec быть не должно. Я ж написал – перехватывать надо свой stdout. Собственный. Похоже я нашёл что нужно, поиграюсь завтра.

Проверку на ошибки сделаешь самостоятельно. И да, можно легко «подвиснуть» на записи в новый stdout, если не читать его постоянно из отдельного потока

#include <stdio.h>
#include <unistd.h>

// returns file descriptor which stdout had been "redirected" to
int hook_stdout()
{
  int pfd[2];
  pipe(pfd);
  dup2(pfd[1], STDOUT_FILENO);
  close(pfd[1]);
  return pfd[0];
}

int main()
{
  char buf[4096];
  // btw if you remove this, program will "hang" without explicit flush,
  // because isatty is called on stdout when it accessed for the first time
  puts("not redirected");
  FILE *f = fdopen(hook_stdout(), "r");
  puts("now redirected");
  //fflush(stdout);
  fgets(buf, sizeof(buf), f);
  fprintf(stderr, "FROM stdout: %s", buf);
  return 0;
}

Сенькс.

И да, можно легко «подвиснуть» на записи в новый stdout, если не читать его постоянно из отдельного потока

Мне 64K с головой. И я буду из этого же потока периодически вычитывать.

stdout, в т.ч. выводимый чужими подлинкованными либами

Извиняюсь за не по теме вопрос. А это вообще нормальная практика, когда линкуемая либа сама что-то в stdout льёт? Мне казалось, что библиотека должна максимум передать использующему её приложению буфер с текстом, а то уже само решит, что с оным делать.

А это вообще нормальная практика, когда линкуемая либа сама что-то в stdout льёт?

Есть многое на свете, друг Горацио, что и не снилось нашим мудрецам.