g++, linux: syncfs was not declared in this scope.
Какие версии ядра и glibc?
$ uname -a
Linux garry 3.2.9 SMP Fri Aug 31 16:51:21 MSK 2012 x86_64 GNU/Linux
$ ldd --version
ldd (Debian EGLIBC 2.13-27) 2.13
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
это?
В glibc только с 2.14: http://www.cygwin.org/ml/libc-hacker/2011-03/msg00005.html
из моего мана:
VERSIONS
syncfs first appeared in Linux 2.6.39; library support was added to
glibc in version 2.14.
ясно, спасибо!
а оно с ядром вместе ставится? Это я его мог затереть?
его обновить как? glibc в списке пакетов что-то не значитя.
Нужно видимо сделать что-то вроде "make installworld". или в линуксе это всё в ядре?
PS: syncfs и fsynс чем-то отличаются? Если я везде заменю syncfs на fsynс мне там руки не оторвут, что всё медленно стало?
а оно с ядром вместе ставится? Это я его мог затереть?
его обновить как? glibc в списке пакетов что-то не значитя.
Нужно видимо сделать что-то вроде "make installworld". или в линуксе это всё в ядре?
PS: syncfs и fsynс чем-то отличаются? Если я везде заменю syncfs на fsynс мне там руки не оторвут, что всё медленно стало?
не, ядро отдельно, glibc — отдельно, надо обновить пакет, называться он может немного по-другому, как в минте, не знаю.
а оно с ядром вместе ставится?Есть ядро, есть хедера ядра, есть libc и есть хедера libc, это всё разные вещи, очевидно.
glibc в списке пакетов что-то не значитя.Mint вроде как растёт из Debian, где glibc нет уже давно, а есть EGLIBC. Пакет смотри по имени libc6.
Я на твоём месте поступил бы так, убедился, что хедера ядра от ядра, которое загружено, само ядро >= 2.6.39, и дёргал бы системный вызов напрямую, мелкий враппер/макрос, конечно, придётся написать.
Я на твоём месте поступил бы так, убедился, что хедера ядра от ядра, которое загружено, само ядро >= 2.6.39, и дёргал бы системный вызов напрямую, мелкий враппер/макрос, конечно, придётся написать.
а нафига?А нафига зависеть от ядра и libc, когда легко можно зависеть только от ядра? В частности напомню, что у топик-стартера проблема возникла из-за перемены libc. Но, как и упомянул, это мой сомнительный вкус, которым делюсь, но не пропагандирую.
main.cpp:10:14: error: 'syncfs' was not declared in this scopeЕсли бы функция отсутствовала, компилятор бы так и написал.
Тут что-то другое, типа "use std;", но я не уверен.
o_O
Ну если так смотреть, то да, но это волевое решение. Раньше зависели только от libc, теперь будем только от ядра.
Раньше зависели только от libcВероятно, я употребляю отношение «зависеть» слишком общо, так что зависимости только от libc (опять-таки от какой из N существующих? будем ли добавлять зависимость сборки libc от ядерных хедеров?) я не наблюдаю ни в ретроспективе, ни в перспективе. В границах рассматриваемого примера тоже зависимости только от libc нет, так как очевидно, что код топик-стартера в окружении linux-2.6.38/libc-2.14 работать не будет.
будем ли добавлять зависимость сборки libc от ядерных хедеров?)я рассматриваю не с той точки зрения, что от чего на самом деле зависит, а просто: пользуемся только libc'шными хедерами, там функция есть, значит все будет ок, а что ей там дальше надо — проблема админа конкретной системы, с точки зрения написания проги проще вроде бы.
Продолжу занудствовать IMHO.
пользуемся только libc'шными хедерамиВ реальной жизни неосуществимо, libc'шные хедера зависят от ядерных. Причём есть билд-зависимость у самой libc при постройке и, независимая от этой, наследованная билд-зависимость у компилируемых программ.
там функция есть, значит все будет окВыше привёл пример, где будет не ок, linux-2.6.38/libc-2.14/syncfs.
что ей там дальше надо — проблема админа конкретной системыНаоборот же, инженеры как более высокоинтеллектуальные существа диктуют админам то, что им требуется предоставить для работы.
с точки зрения написания проги проще вроде быНу, только на самых простых примерах типа hello world и около, то есть прикладном ПО, в системном ПО всё несколько сложнее.
Вероятно, я употребляю отношение «зависеть» слишком общо, так что зависимости только от libc (опять-таки от какой из N существующих? будем ли добавлять зависимость сборки libc от ядерных хедеров?) я не наблюдаю ни в ретроспективе, ни в перспективе.Скажем так, большинство менеджеров пакетов организованы так, что нужная тебе версия libc влечет нужную тебе версию ядра. Поэтому можно положиться только на зависимость от libc, надеясь, что она сделает все остальное.
Прямой зависимости от ядра у тебя не будет, только опосредованная.
В реальной жизни неосуществимо, libc'шные хедера зависят от ядерных.это не логическая зависимость, на нее при написании кода можно положить, это все детали реализации. Я пользуюсь libc => мне пофигу, как оно реализовано: стандартная абстракция интерфейса и реализации.
Причём есть билд-зависимость у самой libc при постройке и, независимая от этой, наследованная билд-зависимость у компилируемых программ.Это все административные вопросы, это все есть и как раз чтобы не морочить себе этим голову, проще зависеть напрямую только от libc. Ты же при написании printf не задумываешься каждый раз, как компилятор этот символ запишет в Undefined, линковщик потом найдет, разрулит, прилинкует, как потом ldd это все подцепит при запуске и т.д. Ибо мы это все знаем, но думать об этом каждый раз не хотим.
Просто ты привык работать на том уровне, где удобно завязываться на ядро, а я бы не стал менять все из-за одной функции, которая и так есть в libc, не вижу смысла вообще в этом.
man 2 syscall
Оставить комментарий
Phoenix
Думаю лучше сюда, чем в h'n's.в мане написано
в общем, все ругают мою установленную linuxmint-debian-edition. Говорят, что на ubuntu всё супер.
я вот не понимаю, неужели библиотеки различаются? в unistd.h действительно нет syncfs.
ещё изыскания.
я переустанавливал ядро, но вроде как .h оно ж не трогает. Может что-то недоустановил, в общем, куда копать?