Свежие комментарии

Title Comment
Тут вот с версиями glibc есть явная чехарда, я ее и хочу про

Тут вот с версиями glibc есть явная чехарда, я ее и хочу прояснить:
У меня в LibRaw используется fopen/fseek/fread/fclose

До недавнего времени я считал, что RAW больше двух гигабайт не бывает и меня все это не парило. Как выяснилось, бывают (с цифровых кинокамер). Имею багрепорт, в двух словах "на Ubuntu работает, на Mac OS X - нет".

Ну и понятно почему на макоси нет - там fseek - 32-битный, fseeko - off_t. Но на Убунте то работает, вероятно в (новых?) glibc сходу все прозрачно.
Но я решил, что уж раз чинить, то чинить все сразу и винды и старый линукс. Про fdopen - интересное замечание, учту.

<b>Re: на компиляции - нужны только Linux _даже_ при использ

Re: на компиляции - нужны только Linux _даже_ при использова
И что характерно, действительно разные показывает nm данные:
U fseeko64@@GLIBC_2.1 - для случая с -D_FILE_OFFSET_BITS=64
и
U fseeko@@GLIBC_2.1 - для случая без
Вай-вай-вай, нужны эти дефайны указывать явно для случая 64 на платформе 32. :-(

<b>Re: на компиляции - нужны только Linux _даже_ при использ

Re: на компиляции - нужны только Linux _даже_ при использова
Подтверждаю, если у меня не передать -D_FILE_OFFSET_BITS=64, то тип off_t будет 4 байта.
Но стоит передать - получается 8 байт. Это касается gcc *.c и g++ *.cpp.

Единственно чего я не понял, то почему включения заголовка stdio.h недостаточно для объявления типа off_t, нужно обязательно ещё sys/types.h, иначе не знает такого имени компилятор.

Вся проблема не в линуксе, а в gcc/libc. Не спозиционируешьс

Вся проблема не в линуксе, а в gcc/libc. Не спозиционируешься, и даже append'ом не запишешь файл за 2 гигабайта, если не стоит O_LARGEFILE при открытии. Как поставить этот флаг при открытии файла на с++ через его потоки я так и не понял, простого пути нет, сложный нафиг не нужен. В итоге, открывал обычным open(2), потом через fdopen уже буферезированный вывод. По дефолту O_LARGEFILE не ставится ни с какими флагами сборки.

<b>CONFIG_RESOURCES_64BIT</b><br/> У меня Linux dememax-lapt

CONFIG_RESOURCES_64BIT
У меня Linux dememax-laptop 2.6.29-gentoo-r5 #3 SMP Wed Jul 29 11:38:42 MSD 2009 i686 Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux

Я себе гонфигурил CONFIG_RESOURCES_64BIT в ядре.
Ща взглянул, у меня вообще никакого упоминания в .config нет.
http://cateee.net/lkddb/web-lkddb/RESOURCES_64BIT.html

<b>Re: Только не в плюсах!</b><br/> фишка в том, что в FreeB

Re: Только не в плюсах!
фишка в том, что в FreeBSD off_t - 8-байтный.

Правда я в любом случае слегка погорячился: переделать на fseeko (и соотв. функцию на виндах) в любом случае надо. А вот какие-то прыжки с флагами препроцессора на компиляции - нужны только Linux _даже_ при использовании fseeko

<b>Только не в плюсах!</b><br/> В старом добром си вы можете

Только не в плюсах!
В старом добром си вы можете слинковать определение func(char) в одном объектнике с использованием func(int) в другом на платформе, где sizeof(int)>sizeof(char) и вам за это ничего не будет... на линкове.

По дефолту, кстати, нет. Но gcc -m64 - да, собирает 64 бита.

По дефолту, кстати, нет.
Но gcc -m64 - да, собирает 64 бита.

а на маках разве не 64 бита?

а на маках разве не 64 бита?

Разгадал - работает на 64 битах без всяких лишних ударов в б

Разгадал - работает на 64 битах без всяких лишних ударов в бубен.

Я то почитаю (почитал уже), но у меня все довольно новое. Оп

Я то почитаю (почитал уже), но у меня все довольно новое. Опасаюся я, что в старых может быть все иначе, потому и спрашиваю про старые.

Впрочем, наверное действительно надо разбираться по мере поступления, работает на 10-й Suse - и отлично, если не работает на старой, там и разберемся.
Интересно, почему у этого англичанина все просто работает, ведь не должно бы.

А по совместимости - я бы сохранил старую точку входа, назвав ее old_lseek, а всю компиляцию всех новых сорцов заворачивал бы в new_cool_64bit_lseek без всяких флагов.

Алекс, ну возьми ты stdio.h с ближайшего линукса и почитай.

Алекс, ну возьми ты stdio.h с ближайшего линукса и почитай. Там все на простом и понятном языке C написано. Даже в исходники libc лезть не придется.

А на вопрос "нахрена так сделано" ответ очевиден - динамическая линковка + требование чтобы старые бинарники работали с новой libc.
Если представить себе как ложатся в стек параметы тех же lseek/lseek64 (да еще во всех вариантах - bigendian/littlendian, процессор ест невыровненные данные/посылает SIGBUS) станет ясно, что единственный способ обеспечить совместимый ABI, это сохранить старую точку входа в динамическую библиотеку со старой семантикой, а рядом - завести новую с другим именем.

У меня в коде написано fopen/fseek/fread (и в одном месте fg

У меня в коде написано fopen/fseek/fread (и в одном месте fgets).
Что вместо fseek нужен fseeko - я уже понял.
Про offset_bits тоже понял.
Конфликта по именам - не будет, как я понимаю.

Вопросы дальше - а через fopen() можно открыть файл больше двух гигов или надо open(... O_LARGEFILE) и fdopen(), как меня пугают в комментах в моем блоге.

Кстати, а нахрена так сложно сделано то? Кто мешал починить внутри, а не выносить все эти lseek64 наружу? В чем фишка, в бинарной совместимости?

С файлами реально не больше 2Gb никаких проблем нету и так,

С файлами реально не больше 2Gb никаких проблем нету и так, все работает.

Ко мне киношники пристали, у них большие файлы (и хрен возьмешь на тест, тоже проблема). Причем, пристали со словами, что на линуксе ("свежая убунту") работает (!), а на маке - нет. Почему не работает на маке - я уже понял, нужен fseeko. На Линуксе тоже он нужен.

А вот как у них получилось, что на линуксе работает - вообще не могу понять.

под рукой линукса нету, есть только &quot;где не надо парить

под рукой линукса нету, есть только "где не надо париться" ;)

но по уму там под этими #ifdef должны разные функции libc вызываться и/или делаться разные syscall. Поэтому если файл реально не больше 2 гб, то проблем быть не должно.

&lt;img src=&quot;http://fudge.logix.cz/gimg/freebsdlinux.jp

<img src="http://fudge.logix.cz/gimg/freebsdlinux.jpg" />

Так это, -D - это установка макроопределения препроцессора.

Так это, -D - это установка макроопределения препроцессора. Уже на этапе собственно компиляции, от этих -D ничего не остается.

Вернее, остануся более другие определения __off_t и lseek64 там где в коде было написано lseek (ну и прочие функции - соответственно), что легко можно проверить посредством gcc -E,

Соответственно скомпилированный объектник будет содержать ссылки на библиотечные функции с 64-битными смещениями, с чем его не линкуй. Другое дело ежели где-то в интерфейсе библиотеки торчат парметры или функции с типом off_t. Вот тут можно на грабли наступить, если разные файлы слинкованы с разными значениями этих макросов.

А все три варианта макросов с точки зрения системных хедеров glibc - практически инварианты. Все равно они все сводятся к внутреннему макросу
__USE_LARGEFILE64.

Ну у меня портились _разные_ приложения. Firefox, Skype, Fee

Ну у меня портились _разные_ приложения. Firefox, Skype, FeedDemon, uTorrent, еще что-то
Firefox и торрент - точно по несколько раз, остальные - вроде по одному. Симптомы одинаковые - отсутствие реакции на раздражители (user input) и либо система сама предлагает снести нахрен, либо убиваешь ручками.

Вполне возможно, что если всем приложениям я бы поставил эту галку - полегчало бы. А может и нет.

Проблема именно в том, что за три дня (пятница-воскресенье) семерка вызвала у меня _раздражение_, а не как Леонов пишет "никакой разницы".

Причем, я охотно допускаю, что дело вообще в антивирусе (как пример), а семерка не виновата. Ну значит надо ждать несколько месяцев до апдейтов всех основных программ, а не SP1, с точки зрения клиента разница на сегодня - невелика.

Ну а накатить бэкап - проще, конечно. Вставил сидюк и пошел пить чай на 15 минут. Если хардвер не менялся, то все происходит само.

Я не системным бэкапом. У меня оно батничком сделано. Но лье

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

Это же одна галка в свойствах EXE&apos;шника. Бэкап явно не

Это же одна галка в свойствах EXE'шника. Бэкап явно не проще.

<b>Re: К сожалению, уже давно было. Но тем не менее...</b><b

Re: К сожалению, уже давно было. Но тем не менее...
;)) всякие причины бывают, но главное результат - что помнишь о человеке, "йа так щитаю" (с) ;)

<b>Re: опять в Крым, на перевоспитание!</b><br/> Я бы с прев

Re: опять в Крым, на перевоспитание!
Я бы с превеликим удовольствием!
Даже обещаю вести себя <a href="http://www.youtube.com/watch?v=mo90RzfpSBI" title="АССА, Александр Баширов, Монолог Шурика">поведением, достойным советского офицера, приношу свои извинения</a>, не так, как в тот раз! :-)))))))))))))

<b>Re: К сожалению, уже давно было. Но тем не менее...</b><b

Re: К сожалению, уже давно было. Но тем не менее...
В-общем, надо тебя опять в Крым, на перевоспитание!

<b>К сожалению, уже давно было. Но тем не менее...</b><br/>

К сожалению, уже давно было. Но тем не менее...
Читаем по ссылке http://www.lexa.ru/lexa/<blockquote>"Персональная информация

Родился 27 июля 1970 года в Москве, ..."</blockquote>Просто, я имел обыкновение звонить. А в этом году - Виталику не позвонил, а до <lj user=vabelov> банально не дозвонился... Короче, осадок остался, пытаюсь исправить. :-)

)))))))))))))) да уж))) Региональность выдачи штука интересн

)))))))))))))) да уж))) Региональность выдачи штука интересная, но уж больно специфическая, имхо. Ой как не для всех сайтов она улучшит выдачу.... Но Яндексоидам виднее, конечно, что со своей ПС делать... У меня довольно интересные наблюдения относительно них наклёвываются на mytravelog.org: посетители с Яндекса имеют на 70% лучшее страниц/посещение и на 25% меньший показатель отказов (все относительно Гугла). Очень заметные различия, кажется. Правда, Яндекс приносит почти втрое меньше народу, что тоже важно, но может и другим объясняться. В общем, то ли они умеют качественнее ранжировать большие тексты, то ли одно из двух...

Пойду, что-ли свои сайты проверю... ;))

пс: если там про Д.Р. всё верно писали, то я присоединяюсь к поздравлениям)

Сильно лучше - но только по разрешению в зелёном (и на камер

Сильно лучше - но только по разрешению в зелёном (и на камерах, не страдающих вырождением зелёного). IMHO хроматическая аберрация - та же, малоприемлемая.

http://www.schneideroptics.com/ecommerce/CatalogSubCategoryD

http://www.schneideroptics.com/ecommerce/CatalogSubCategoryDisplay.aspx?...

Тоько shift (можно модифицировать на только tilt у Z RK), но лучшего я не знаю.

<b>&quot;Две лоботомии по цене одной!&quot;</b><br/> Лёха, д

"Две лоботомии по цене одной!"
Лёха, дорогой!

С прошедшим тебя!
(В этом году - не позвонил я тебе...)

Всех тебе благ!
Оставайся всегда таким же жизнерадостным и добрым!

сильно у мя валалась шторка от киева 6*6, от астрономов, пр

сильно

у мя валалась шторка от киева 6*6, от астрономов, прожжёная светом даааалёкой звезды, то есть может быть солнцем но хочется верить в сказку.

В постпроцессинге можно много всего придумать. Но хочется в

В постпроцессинге можно много всего придумать.

Но хочется в RAW-конверторе, до интерполятора, пока все не разбежалось.

Pages

Subscribe to comments_recent_new