These option clashes happen when a package is requested to be loaded on two different positions, like by you and inside another package, but with different options. The package is loaded by the first \usepackage (or its twin \RequirePackage); it isn't loaded again when it is requested again. It simply can't be loaded a second time. Therefore the new options can be activated and previous options might conflict with the second usage. So LaTeX creates an error to report this issue to you.
The way to fix this is to declare the options beforehand using \PassOptionsToPackage{<options>}{<package>}. Then they are used wherever the package is loaded.
\documentclass{article}
\usepackage{ifpdf}
\ifpdf
\PassOptionsToPackage{pdftex,usenames,dvipsnames}{color}
\usepackage[T1]{fontenc}
\usepackage{libertine} % most likely loads 'color' itself
%\usepackage{lmodern} % doesn't load 'color'
\usepackage{color}
\usepackage[pdftex]{graphicx}
\else
%\bye
\fi
\begin{document}
Hello, world!
\end{document}
I can't test it by myself, because I don't have the libertine package installed.
PS:
I don't think you need to set pdftex manually. Normally packages do a good job recognizing the driver by themselves. Also you might want to use the extended xcolor package instead of color.
Too long for a comment.
Can you try the following example?
\documentclass{article}
\begin{document}
Hello
\pdfsetmatrix{.52495 0 0 .52495}
World
\end{document}
If it breaks, what happens if the \pdfsetmatrix line is replaced by the following?
\pdfsetmatrix{2 0 0 2}
or
\pdfsetmatrix{2.0 0.0 0.0 2.0}
So far I could not reproduce the problem, neither with TL nor MiKTeX.
pdftex.def 2011/05/27 v0.06d, md5sum=3C8A0D99822330F2DFABC0DFB09CE897
graphics.sty 2009/02/05 v1.0o
graphicx.sty 1999/02/16 v1.0f
This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013)
This is pdfTeX, Version 3.1415926-2.5-1.40.14 (MiKTeX 2.9) (preloaded format=pdflatex 2014.2.18)
CQL.pdf: size=2312 md5sum=8D0D2F67766E6E135B1B70B09BCA5CCA
pdfTeX can calculate MD5 checksums:
\typeout{md5(CQL.pdf)=\pdfmdfivesum file{CQL.pdf}}
As far as I can see, the versions are the same.
Also you have output the argument from \pdfsetmatrix (from this answer):
\let\orgpdfsetmatrix\pdfsetmatrix
\renewcommand*{\pdfsetmatrix}[1]{%
\typeout{* setmatrix: [#1]}%
\orgpdfsetmatrix{#1}%
}
The output looks correct:
* setmatrix: [.52495 0 0 .52495]
Thus the only difference I can find is the binary. Are you using the 64bit version? I have tested with the 32bit version of MiKTeX.
Therefore I think, the problem is worth investigating, but difficult, because it seems that it cannot be easily reproduced.
Addition from the comment from Acrofales:
\pdfsetmatrix{2.0 0.0 0.0 2.0} breaks, the variant without dots \pdfsetmatrix{2 0 0 2} works.
From the source code pdftexdir/utils.c:
typedef struct {
double a;
double b;
double c;
double d;
double e;
double f;
} matrix_entry;
...
integer pdfsetmatrix(poolpointer in, scaled cur_h, scaled cur_v)
{
matrix_entry x, *y, *z;
char dummy;
if (page_mode) {
if (sscanf((const char *) &strpool[in], " %lf %lf %lf %lf %c",
&x.a, &x.b, &x.c, &x.d, &dummy) != 4) {
return 0; /* failure */
}
...
}
The manual page says about %lf:
l: Indicates ... that the conversion will be one of e, f, or g
and the next pointer is a pointer to double (rather than float).
Perhaps this is not true for the Compiler MiKTeX uses for its 64bit version, Microsoft Visual C++ 2008 according to the build instructions for Windows.
This can also explain the security violations, if the variable sizes do not match for sscanf and memory is written outside the variables.
Best Answer
I ran into the same problem and now use this...